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1.  FOREWORD 


This  document  provides  information  concerning  development  for  the  Air  Force  contract 
#F33615-98-C-3208  titled  Air  Vehicle  Configuration.  The  Air  Force  Research 
Laboratory  /  Air  Vehicle  program  monitor  in  this  effort  is  Dr.  Max  Blair.  TechnoSofit 
Inc.  (TSI)  provided  the  contracted  effort  as  a  prime  contractor  with  Purdue  University 
(PU)  and  Samara  State  University  (SSU)  serving  as  subcontractors.  The  Principle 
Investigators  were  as  follows: 

TSI:  Adel  Chemaly, 

PU:  Dr.  Terrence  Weisshaar, 

SSU:  Dr.  Alexander  Danilin  and  Dr.  Valery  Komarov. 

The  objective  of  this  research  was  to  develop  a  comprehensive  design  environment  and 
framework  for  modeling  and  simulating  aircraft  systems  that  seamlessly  integrates 
different  engineering  processes.  This  framework  for  Air  Vehicle  Configuration  (AVC) 
covers  not  only  the  accurate  definition  of  the  external  shape  on  which  lift  and  drag 
depend,  but  it  also  includes  the  preliminary  sizing  of  structural  elements  that  tend  to  drive 
the  weight  of  the  vehicle  and  tend  to  influence  the  size  of  critical  loads. 
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2.  Summary 

The  repetitive,  iterative  nature  of  air  vehicle  design  and  the  conflicting  requirements  for 
performance  and  affordability  present  a  challenge  to  provide  a  comprehensive  design 
system  to  integrate  toe  various  engineering  stages.  Capturing  and  modeling  the 
engineering  philosophies  as  related  to  the  design  evolution  from  concept  to  production 
details  must  be  done  to  enable  quick  response  to  changes  in  designs,  materials,  and 
processes.  Automating  and  integrating  the  various  engineering  cycles  will  speed  the 
desi^  process  and  provide  high  fidelity  guidance  for  designers  to  interact  across 
disciplinary  barriers  and  to  assess  viability  of  toe  design  and  to  define  and  to  reduce 
economic  risk.  This  document  reports  work  performed  regarding  the  aforementioned 
topics  under  Air  Force  STTR  contract  #F33615-98-C-3208  titled  Air  Vehicle 
Configuration. 

The  methodology  of  the  developed  AML  modules  is  explained  and  documentation  for  the 
AML  modules  is  given  in  the  Appendices.  The  effort  included  integrating  basic 
structural  design  capability  into  the  AML  aircraft  design  code  being  developed  by 
Technosoft.  Dr.  Danilin  worked  with  TechnoSoft  personnel  to  integrate  his  DRACO 
code  as  part  of  the  AML  modules.  The  Appendices  also  include  a  summary  of  the  finite 
element  type  used  by  Dr.  Danilin  in  his  AML  work  at  TechnoSoft  and  a  paper  written  by 
Dr.  Weisshaar,  based  upon  Dr.  Danilin’s  work  in  design,  in  which  the  AML  procedure  is 
mentioned.  The  paper  written  by  Dr.  Weisshaar  was  presented  at  the  40'^  AIAA/ 
Structural  Dynamics  and  Materials  Conference  in  Atlanta,  Georgia  in  April  2000. 


TechnoSoft,  Purdue,  and  Dr.  Danilin  demonstrated  examples  of  the  technology  to  the  Air 
Force  Research  Laboratoiy  personnel  in  August  1999  with  a  sample  fuselage  bulkhead 
and  wing  desi^.  Dr.  Danilin  and  Dr.  Komarov  also  submitted  a  description  of  their 
special  sandwich  element  as  required  and  also  made  themselves  available  for 
consultation. 

Professor  Weisshaar  provided  services  while  Dr.  Danilin  was  in  this  country.  He  also 
helped  in  preparation  of  toe  final  report  and  helped  present  results  that  showed  the 
versatility  of  the  methods  used  by  AML. 

3.  Design  Architecture  and  Framework 

The  objective  of  this  research  was  the  development  of  a  comprehensive  design 
environment  and  framework  for  modeling  and  simulating  aircraft  systems  that  seamlessly 
integrates  different  engineering  processes.  This  framework  covers  not  only  the  accurate 
definition  of  the  external  shape  on  which  lift  and  drag  depend  and  the  arrangement  of 
internal  contents  in  a  straightforward  manner,  but  it  also  includes  the  preliminary  sizing 
of  structural  elements  that  tend  to  drive  the  weight  of  toe  vehicle  and  tend  to  influence  the 
size  of  critical  loads. 


2 


Feedforward 


Feedforward 


Ir  I - 1 


Mission/ 

Conceptual 

Preliminary 

Detailed 

Metrics 

Cost 

Performance 

Specification 

Model 

Model 

Model 

◄ — 

t _ I  t 


Feedback  Feedback 


Figure  1:  Design  Process 

Based  on  the  Adaptive  Modeling  Language  (AML),  the  system’s  framework  supports  a 
single  underlying  object-oriented  architecture  with  demand-driven  computation  and 
dependency  tracking  that  allows  information  to  feed  forward  and  backward  among  the 
various  design  levels  and  engineering  processes  as  the  design  evolves  as  shown  in  Figure 
1. 

The  system  architecture  is  based  on  a  modular  framework;  each  module  focuses  on  an 
engineering  discipline  or  component  design  application.  This  supports  the  seamless 
integration  of  various  tools  and  applications  in  the  aircraft  design  process.  An  appealing 
feature  of  this  architecture  allows  design  tools  to  evolve  or  be  updated  without  requiring 
changes  to  the  interface  within  the  architecture.  Multiple  tools  may  be  made  available  to 
the  designer  that  serve  the  same  purpose.  This  will  allow  designers  to  select  the 
appropriate  level  of  analysis  for  their  particular  task.  It  will  also  allow  for  mixed  design 
modes,  with  some  analyses  performed  at  a  low-order  conceptual  level  while  others  are 
done  at  a  high  fidelity,  preliminary  level. 

The  framework  has  two  foci: 

1)  Constructing  and  linking  together  conceptual,  preliminary,  and  detailed  models, 

2)  Seamlessly  integrating  engineering  processes  and  tools. 

A  limited  prototype  was  developed  to  illustrate  the  design  process;  this  prototype  focuses 
on  wing  structure  conceptual  and  preliminary  design  and  analysis  and  its  use  was 
demonstrated.  Preliminary  versions  of  two  modules  were  implemented.  These  modules 
focus  on  early  geometric  configurations  and  preliminary  structural  and  aerodynamic 
analyses. 

4.  Technical  Approach 

The  modeling  of  the  air  vehicle  considered  during  the  effort  focused  on  the  fuselage, 
inlets,  and  wing  structure.  This  research/development  effort  produced  a  system 
framework,  architecture,  and  a  set  of  development  modules  to  model  and  link  strategies 
and  engineering  processes  involved  in  aircraft  conceptual  and  preliminary  design.  TTie 
framework  provides  an  architecture  and  modules  supporting  an  engineering  environment 
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for  the  conceptual  design,  configuration,  and  first-order  analysis  of  an  air  vehicle  system. 
In  addition,  the  system  modules  enable  the  modeling  and  automation  of  important 
engineering  analysis  processes  to  follow  the  design  evolution  from  the  conceptual  to  the 
preliminary  stages.  As  a  result,  the  system  modules  provide  not  only  the  basic  capability 
for  the  conceptual  design  of  an  air  vehicle,  but  also  allow  the  design  team  to  proceed  to 
the  design  definition  at  a  high  level  of  fidelity,  consistent  with  the  requirements  of  major 
vehicle  components  and  engineering  analysis  processes. 

The  framework  involves  a  combination  of  low-level  classes/methods/functions  for  air 
vehicle  design,  a  common  computational  model  for  these  classes,  and  an  encompassing 
hierarchy  for  the  classes  to  be  used  (instantiated)  into  an  end-user  environment.  The 
following  domain-specific  modules  have  been  developed: 

1 .  Geometry/Component  configuration  builder  and  complex  surface  modeler 

2.  Finite  element  interface  to  Patran  and  innate  panel-based  mesher 

3.  Structural  analysis  interface  with  Dracon 

4.  Aerodynamic  analysis  interfaces 

Following  an  elaboration  on  the  underlying  AML  framework,  each  of  these  modules  is 
descnbed  m  the  following  sections  along  with  a  sample  end-user  environment 
demonstrating  their  use  in  an  integrated  framework  for  air  vehicles.  AML  developer 
documentation  is  provided  in  the  Appendices  for  several  of  these  modules. 


4.1.  AML  Framework 

This  work  is  based  on  the  Adaptive  Modeling  Language  (AML),  offered  commercially  by 
TechnoSoft  Inc.,  for  knowledge-based  concurrent  engineering  and  comprehensive 
modeling  that  integrates  design  specifications,  part  geometry  and  features,  manufacturing, 
inspection,  and  analysis  processes  in  a  unified  part  model.  AML  provides  a  KBE 
framework  that  captures  knowledge  from  the  modeled  domain  and  creates  parametric 
models  with  that  knowledge.  Classes  inheriting  from  AML  primitives  may  be  defined 
and  methods  may  be  written  against  these  classes  providing  user-defined  behavior.  After 
defining  the  classes,  a  hierarchical  part  model  is  initiated  where  the  attributes  of  objects 
can  be  related  using  constraints.  This  part  model  may  be  used  as  a  parametric  design  in  a 
what-if  scenario  by  changing  design  parameters  and  re-computing  the  model  as  the 
changes  are  propagated  through  the  model  on  demand.  In  addition,  AML  is 
dimensionless  and  may  be  adapted  to  support  any  dimension  units. 

Various  aspects  of  a  problem  can  be  detailed  through  a  single  unified  model  in  AML.  An 
example  of  such  an  application  is  structural  design.  A  geometric  design  is  created  and 
vanous  physical  attributes  are  associated  with  the  geometry.  Then,  the  attributes  for  a 
finite  element  mesh  and  the  knowledge  required  for  generating  input  files  for  analysis  is 
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maintained.  AML  allows  this  information  to  be  stored  in  a  single  stractixred  model.  A 
complete  user  interface  for  the  problem  including  input  and  output  forms,  menus,  etc., 
can  also  be  associated  with  the  same  part  model  that  encompasses  the  various  aspects  of 
the  application.  The  paradigm  provides  a  common  interface  to  a  number  of  solid 
modelers  in  addition  to  different  mesh  generators  and  FEA  solvers.  The  virtual  layer 
interface  provides  a  common,  consistent  interface  to  achieve  this. 

The  proposed  system  is  composed  of  several  AML  modules  (sets  of  classes  and  methods) 
relating  to  the  different  knowledge  domains  and  each  performing  a  different  function  as 
required  by  the  various  engineering  disciplines.  All  the  modules  in  the  system  can  be 
integrated  within  the  AML  object-oriented  architecture  through  the  Common 
Computational  Model  (CCM  -  see  following  paragraphs  for  further  explanation), 
although  they  may  communicate  with  external  programs  through  the  virtual  layers.  Since 
AML  is  modular,  only  the  necessary  systems  need  to  be  loaded  into  AML.  Hence,  if  a 
problem  requires  a  modeling  framework  but  no  graphics  or  geometry,  only  the  kernel 
needs  to  be  loaded  for  that  application.  Applications  invoking  different  aspects  of  the 
proposed  system  built  in  AML  use  a  common  user  interface  to  the  system.  Hence,  user 
familiarization  is  required  only  with  one  interface  irrespective  of  the  applications. 

The  lowest  level  AML  object  provides  the  language  consfructs  for  defining  classes, 
methods,  and  functions,  as  well  as  the  creation  of  objects,  constraints,  and  a  tree 
hierarchy.  All  subsequent  objects  augment  the  language.  A  part/sub-part  relation  enables 
the  creation  of  a  tree-structured  unified  model  where  the  children  of  any  node  of  the  tree 
represent  sub-objects  thus  creating  an  organized  data  hierarchy.  Various  aspects  of  the 
problem  can  be  structured  hierarchically  according  to  the  domain  being  modeled  (design, 
analysis,  manufacturing,  and  inspection). 

Each  portion  of  this  hierarchy  supports  AML’s  underlying  constraint  mechanism  and 
demand-driven/dependency-backtracking  behavior.  Demand-driven  means  that  the  value 
of  a  property  is  not  calculated  until  it  is  required  (demanded).  Until  a  value  is  demanded, 
an  internal  flag  refers  to  the  property’s  value  as  being  unboxmd  or  the  property  as  being 
smashed.  Hence  several  properties  that  affect  another  property  can  be  modified,  but  the 
affected  property  is  not  recalculated  with  each  change;  only  when  needed  (demanded). 
Dependency  tracking  is  the  mechanism  that  propagates  constraint  changes  throughout  the 
part  model.  When  a  property  is  modified,  all  the  properties  it  effects  become  unbound  or 
smashed  (not  currently  valid).  When  a  property  is  smashed,  it  further  smashes  all 
properties  that  it  effects,  hence  propagating  the  change  by  notifying  entities  that  they  need 
to  be  recalculated  when  next  demanded. 

Various  applications  of  AML,  including  CAD,  layout  and  configuration,  CAM,  and 
FEM/FEA,  have  different  geometric  requirements.  These  individual  requirements  are 
satisfied  by  augmenting  the  part  model  for  different  representations  in  order  to  satisfy  the 
demands  of  various  applications.  These  different  representations  are  manipulated  through 
a  unified  part  model.  AML  presents  a  nximber  of  objects  or  classes  for  modeling  complex 
geometrical  operations  in  addition  to  simple  primitives.  Complex  operations  for  mixed¬ 
dimensional  solid/surface/wire  frame  Booleans,  incorporating  non-manifold  topology,  are 
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also  supported.  Additional  objects  for  advanced  modeling  of  ffee-form  surfaces 
(NURBS,  Beziers,  etc.)  are  also  available.  The  system  supports  IGES,  STEP,  and  DXF 
interfaces  to/ffom  external  CAD  systems  along  with  various  graphic  visualizations  and 
geometric  reasoning  techniques. 

AML  provides  a  complete  set  of  Graphical  User  Interface  (GUI)  classes,  including  forms, 
buttons,  radio  boxes,  check  boxes,  input  forms,  and  pop-up  menus  supported  on 
Unix/Motif  and  Windows  platforms.  Since  the  user  interface  model  is  represented  using 
the  same  knowledge  representation  system  and  syntax  as  the  rest  of  the  application,  it  too 
is  dynamic  in  nature  and  the  attributes  of  user  interface  entities  can  be  altered  dynamically 
depending  on  the  model's  state. 

AML  allows  the  integration  for  modules  or  programs  that  run  outside  of  AML  (external 
codes),  through  the  use  of  wrapping  objects  and  functions  to  allow  for  their  access.  The 
modules  for  conceptual  design,  geometry,  and  many  of  the  first-order  analyses  were 
vmtten  directly  in  AML  and  integrated  with  external  codes  through  AML’s  foreim 
function  interface.  ^ 


4.2.  Geometry/Component  configuration  builder  and  Complex  surface  modeler 

A  major  goal  of  the  effort  was  the  development  and  implementation  of  an  engineering 
fi'amework  architecture  that  enables  the  layout,  configuration  and  sizing  of  the  major 
aircraft  components.  The  focus  was  on  a  generic  suite  of  classes  and  functionality  to 
enable  the  designer  to  create  and  configure  components  in  an  organized  fashion.  This  can 
then  be  applied  specifically  to  a  fuselage,  wings,  inlets,  engines,  and  payload  for  example. 

The  implemented  architecture  serves  as  part  of  the  AML  object-oriented  framework 
supporting  a  sophisticated  interactive  3D  graphical  system  that  enables  the  manipulation 
of  the  sizing  and  position  of  vehicle  components.  The  system  also  incorporates  a  3D 
visualizer  with  support  for  high-end  graphic  functionality  including  interactive  rotation, 
zooming,  and  rendering.  The  system  enables  the  conceptual  modeling  of  the  vehicle 
using  a  layout  of  the  vehicle’s  outer  skin  for  a  fuselage  and  wing  using  a  series  of 
constrained  cross-sections  and  reference  coordinate  systems.  These  cross-sections’ 
dimensions  and  orientations  are  dependent  on  certain  conceptual  vehicle  parameters  and 
additional  user  input.  The  system  enables  easy  referencing  and  parametric  association  for 
feature  properties  that  could  be  linked  to  external  processes  as  a  part  of  the  virtual  layer 
interface. 


For  layout  and  configuration,  components  may  be  placed  anywhere  within  the  model  and 
their  positions  can  be  specified  relative  to  other  components  or  to  the  aircraft  coordinate 
fi'ame.  Each  component  may  have  its  own  coordinate  frame.  Once  the  positions  and 
orientations  are  specified  and  their  dependencies  set,  moving  the  reference  component 
will  update  the  position  of  any  dependent  components.  For  example,  some  components, 
such  as  fuel  tanks  and  ducts,  can  be  specified  by  connecting  cross-sections.  These  cross- 
sections  are  placed  in  the  same  manner  as  other  components  (using  relative  positions).  In 
addition,  the  cross-sections  of  pre-existing  components  may  be  used.  If  any  of  the  cross- 
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sections  move  (due  to  the  changing  position  or  size  of  the  components  to  which  they  are 
anchored),  then  the  duct-like  components  will  automatically  adjust. 

Once  the  components  are  placed,  their  outer  boundaries  can  be  used  to  establish  the 
constraints  on  the  construction  of  the  fuselage  outer  skin.  Minimum  clearance  constraints 
can  be  imposed  for  sizing  the  outer  surface  model  to  allow  for  the  subsystem  layout  and 
substructure  sizing. 

The  wing  geometry  can  be  handled  with  the  same  type  of  cross-section  configuration  as 
the  fuselage.  In  this  case,  the  cross-sections  can  be  airfoils.  The  wings  are  placed  in  the 
aircraft  in  the  same  way  as  fuselage  components.  The  wings  are  divided  into  portions 
with  each  portion  described  by  a  root  and  tip  airfoil  and  the  wing  can  have  properties  such 
as  twist,  dihedral,  and  sweep. 

The  wing  geometry  can  be  handled  with  the  same  type  of  cross-section  configiuation  as 
the  fuselage.  In  this  case,  the  cross-sections  can  be  airfoils.  The  wings  are  placed  in  the 
aircraft  in  the  same  way  as  fuselage  components.  The  wings  are  divided  into  portions 
with  each  portion  described  by  a  root  and  tip  airfoil  and  the  wing  can  have  properties  such 
as  twist,  dihedral,  and  sweep. 

To  better  illustrate  the  process  of  building  vehicle  components  an  example  of  how  a 
fuselage  is  constracted  is  described  in  the  following  paragraphs. 

The  user  of  the  system  specifies  some  basic  fuselage  properties  (type  of  nose,  length  of 
nose,  radius  at  nose,  curvatrue  at  nose,  . . .).  Using  these  properties  a  set  of  construction 
cross-sections  and  of  scaling  curves  is  generated.  The  cross-sections  and  the  scaling 
curves  are  used  to  construct  the  fuselage’s  outer  mold  surface.  The  outer  mold  surface 
geometry  contains  mesh  data  that  can  be  used  to  generate  aero  decks  used  by  aero 
analysis  codes.  The  strategy  described  above  is  used  to  build  the  wings  and  tails,  and  can 
be  used  to  build  any  component  geometry. 
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Figure  2:  Fuselage  Design 

By  defining  the  fuselage  parameters  the  system  automatically  generates  the  cross-sections 
and  the  scaling  curves  as  shown  in  Figure  2. 


.'!irrfxnNoSo>Tl\r 


Figure  3:  Fuselage  Surface 


Using  the  cross-sections  and  the  scaling  curves  TechnoSoft  Inc.  has  developed  an 
effective  and  easy  methodology  for  building  a  surface. 
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Figure  4:  Mesh  Surface 


In  addition  to  the  outer  mold  surface,  a  quad  mesh  is  generated  as  seen  in  Figure  4 
allowing  the  user  to  generate  data  that  ean  be  used  by  the  aero  analysis  codes. 

For  a  list  of  AML  functionality  available  in  this  module,  please  see  Appendix  1 . 


4.3.  Finite  element  interface  to  Patran  and  innate  panel-based  mesher 

AML  contains  classes  for  attribute  tagging  and  propagation  to  facilitate  the  association  of 
information  with  entities  in  a  geometric  model.  This  information  typically  needs  to  be 
conveyed  to  downstream  processes  (manufacturing,  inspection,  meshing,  or  analysis).  In 
a  parametric  modeling  environment,  reconfiguring  a  model  involves  modifying 
parameters  at  the  construction  level  and  regenerating  the  geometric  model.  Hence,  all 
supplementary  information  would  need  to  be  conveyed  to  the  final  model  as  well  as 
downstream  processes  every  time  the  model  is  reconfigured.  First,  using  attribute 
tagging,  supplementary  information  is  associated  with  configurable  construction 
geometry.  Next,  every  downstream  operation,  including  final  design,  analysis,  and 
manufacturing,  has  the  information  passed  on  through  attribute  propagation. 

As  a  result,  when  the  model  is  reconfigured  (i.e.,  upstream  design  entities  are  modified  in 
geometric  or  other  properties),  the  attribute  propagation  mechanism  ensures  that 
supplementary  information  is  passed  downstream  automatically.  The  attribute  tagging 
and  propagation  mechanism  is  integrated  with  the  demand-driven  and  backward- 
propagation  mechanism  using  event  properties. 

The  automatic  mesh  generation  system  is  an  AML  module  that  allows  tight  integration  of 
various  mesh  generation  and  analysis  applications.  The  system  provides  a  virtual 
interface  to  support  various  third-party  mesh  generators.  The  system  permits  selection  of 
the  geometry  to  mesh,  tagging  the  vertices,  edges,  and  faces  of  geometry  for  selective 
refinement  of  the  mesh,  and  meshing  the  geometry  by  calling  the  external  mesh  generator. 


It  provides  objects  for  meshing,  as  well  as  a  user  interface  along  with  methods  and  a  user 
interface  for  visualizing  the  mesh  by  querying  the  mesh  database  created  by  the  mesh 
generator.  This  effort  has  extended  AML’s  virtual  layer  interface  to  link  with  MSC’s 
Patran  mesher.  Through  the  attribute  tagging  objects,  attributes  can  be  attached  to  the 
edges  to  initiate  the  seeding  of  the  mesh.  When  changes  are  made  to  the  model  geometry, 
the  finite  element  geometric  model  and  all  topology  are  automatically  regenerated  with  all 
the  appropriate  meshing  attributes,  which  is  then  passed  on  to  the  Patran  mesh. 
Implementation  focused  on  surface  meshing  since  the  finite  element  model  requirement 
for  the  analysis  of  the  air  vehicle  skins  and  substructure  is  completely  made  of  shell 
elements. 

Included  in  this  new  interface  is  the  finite  element  analysis  (FEA)  system  that  enables  the 
definition  of  an  analysis  problem  by  defining  regions  of  interest,  material  models, 
solution  strategies  and  other  requirements  for  analyzing  various  problems  using  Patran 
and  a  finite  element  solver  such  as  Nastran  or  Dracon.  Various  air  vehicle  components 
are  modeled  as  AML  classes  that  can  be  used  to  initiate  a  complete  FEA  problem  model. 
The  problem  can  be  associated  with  the  geometric  objects  as  well  as  the  mesh.  The 
system  generates  several  files  that  the  solver  can  read  and  execute  to  generate  results. 
Additionally,  this  system  is  modular  and  can  be  extended  to  provide  a  virtual  solver  layer 
that  can  talk  to  various  other  FEA  solvers. 

TechnoSoft  has  also  created  several  innate  paving  algorithms  within  the  fi-amework 
architecture  to  automate  the  complete  quad-panel  mesh  paving  process.  Classes  have 
been  developed  to  enable  the  user  to  model  the  strategy  for  the  quad-panel  models  based 
on  the  parametric  feature-based  geometry  and  its  associated  material  model.  The  quad- 
based  finite  element  model  is  then  automatically  generated  including  all  input  for 

boundary  conditions,  loads  distribution,  etc.,  as  required  for  a  panel-based  solver  such  as 
PANAIR. 

For  a  list  of  AML  functionality  available  in  this  module,  please  see  Appendices  1  and  4. 

4.4.  Structural  analysis  interface  with  Dracon 

The  conceptual  designer  often  relies  on  previous  experience  to  ensure  that  sufficient 
space  IS  provided  for  required  structural  members.  Many  times,  the  only  consideration  of 
structures  during  the  conceptual  design  phase  is  related  to  weight  estimation.  This  is  not 
really  structural  design  and  this  process  subjects  the  conceptual  design  phase  to  undue 
nsk.  The  statistical  methods  usually  used  in  conceptual  design  stages  limit  design 
creativity  and  do  not  permit  low  risk  investigation  of  radical  new  designs  using  new 
materials  and  manufacturing  processes.  In  this  system,  the  consideration  of  analysis 
includes  a  first-order  analysis  of  critical  loads  and  use  of  these  loads  to  perform  initial 
structural  analysis  for  preliminary  structural  sizing  and  weight  estimation. 


Purdue  and  its  partner  Samara  State  worked  with  TechnoSoft  to  add  functional  capability 
to  the  AML  code  by  developing  a  finite  element  analysis  integration  with  the  Dracon 
fimte  element  solver  and  optimizer  as  well  as  a  library  of  design  elements  that  support 
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both  low  order  modeling  and  cost/weight  optimization  at  the  conceptual  level  along  with 
high  fidelity  modeling  and  cost/weight  optimization  at  the  preliminary  design  level.  This 
modeling  includes  the  ability  to  define  the  structural  geometry/topology,  its  weight  and 
stiffiiess,  and  to  assess  the  quality  of  the  aero/structural  design.  The  models  and  methods 
used  are  proven  techniques  that  have  been  developed  scientifically  overseas,  but  have  not 
been  captured  in  an  effective  way  until  now.  The  team  examined  computational  issues 
and  new  scientific  theories  to  develop  numerical  procedures  to  enable  these  techniques  to 
be  used  with  confidence  in  the  AML  environment. 

The  first-order  analysis  methods  enable  the  initial  layout  of  overall  configuration  and  the 
sizing  of  substructures  such  as  wings  and  bulkheads.  Analysis  links  to  higher-level 
analyses  are  also  included.  This  finite  element  based  analysis  allow  the  modeling 
strategies  to  reduce  the  number  of  cycles  required  to  decompose  the  model  and  generate 
the  required  next  level  finite  element  model.  The  framework  architecture  allows  the 
designer  to  switch  and  combine  levels  of  analysis  (such  as  a  fast,  low-level  aerodynamics 
solution  combined  with  higher-level  structural  analysis). 

The  Dracon  program  has  algorithms  for  structural  layout  and  stiffening  based  on  load 
paths  and  shape  constraints.  These  algorithms  have  been  tightly  integrated  with  the 
overall  fi'amework  to  enable  the  layout  and  sizing  of  structure  early  in  the  conceptual 
design  stage.  These  algorithms  are  based  on  solid  theory  following  an  innovative 
scientific  process  that  still  requires  finite  element  models  but  does  not  require  the 
computation  power  of  a  standard  finite  element  solver  and  is  focused  toward  the  overall 
shape  definition,  sizing,  and  layout  of  the  structures.  This  successful  technology 
developed  by  Dr.  Valery  Komarov,  Dr.  Alexander  Danilin,  and  their  associates  has  been 
tested  suecessfully  at  Purdue  University  by  Professor  Weisshaar  and  his  group. 

The  Dracon  analysis  models  can  be  integrated  as  part  of  the  overall  engineering 
fi'amework.  These  models  can  be  integrated  with  the  concept  model  for  providing  the 
designer  with  feedback  during  the  early  design  stages.  Advanced  visualization  techniques 
have  been  developed  to  allow  the  presentation  of  the  analysis  results  superimposed  on  the 
model  geometry.  The  classes  developed  can  be  used  for  the  output  from  Dracon  as  well 
as  other  solvers. 

The  funetionality  developed  in  AML  Dracon  module  allow  the  user  to  choose  from 
among  several  finite  elements  and  lay  out  a  preliminary  structural  design  that  can  then  be 
optimized  to  find  a  theoretically  optimal  structure  and  estimate  the  weight  of  this 
structure.  This  ability  to  optimize  was  not  originally  called  for  in  the  contract  but  was 
furnished  by  Dr.  Danilin  at  no  charge  to  the  contract.  This  theoretically  optimal  structure 
will  display  Main  Force  Flows  (MFF's'  that  are  useful  for  the  design  stage). 

In  this  development  effort,  the  Samara  team  has  developed/researched  descriptions  of 
theory  and  algorithms  of  structural  and  weight  estimation  for  flat  and  wing-like  structures 
with  stress  constraints,  which  include  a  set  of  finite  elements  with  all  necessary 
algorithms  for  the  creation  of  stiffness  matrices.  These  elements  include: 
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•  Classic  rod 

•  Advanced  membrane  element 

•  Advanced  shear  element 

•  I-Beam  element 

•  Special  element  sandwich  element  for  FEM-I  modeling  (Danilin’s  own  development) 

A  description  of  the  sandwich  element  is  given  in  the  Appendix,  while  the  other  elements 
are  standard  elements  available  in  the  open  literature  and  are  thus  not  documented  here. 

An  AML/DRACON  module  was  developed  and  tested  while  Dr.  Danilin  was  at 
TechnoSoft’s  facility.  Dr.  Danilin  accomplished  his  work  on  an  accelerated  schedule  and 
was  finished  in  August  1999. 

For  a  list  of  AML  functionality  available  in  this  module,  please  see  Appendix  5. 


4.5.  Aerodynamic  analysis  interfaces 

TechnoSofl  has  developed,  as  well  as  extensively  used,  the  aerodynamic  analysis 
methodologies  considered  in  this  work.  Work  has  been  done  to  explore  tools  for  the 
entire  range  of  Mach  number,  dynamic  pressure  and  vehicle  configuration  shape.  A  need 
exists  to  understand  the  use  of  these  aerodynamic  tools  in  developing  data  sets  that  have 
the  appropriate  level  of  detail  for  the  calculations  that  are  to  be  done.  Table  1  lists  the 
aerodynamics  tools  that  were  interfaced,  with  their  respective  capabilities. 


INDEPENDENT 

VARIABLE 

AERODYNAMICS  TOOL 

Missile  DATCOM 

PANAIR 

Mach  Number 

0.0  -25.0 

0-0.9999 

1.0001-4.0 

Body  Shape 

Axis-symmetric 

Elliptical 

Arbitrary 

(Nose  Type) 

Subsonic: 

Transonic: 

Supersonic: 

Hypersonic: 

Sharp 

Sharp 

Arbitrary 

Arbitrary 

Arbitrary 

N/A 

Arbitrary 

N/A 

Angle  of  Attack 

“180  to +180  deg. 

Linear  region 

Sideslip  Angle 

-180to+180deq. 

Linear  region 

Roll  Angle 

0  to  360  deg. 

0  to  360  deg. 

Altitude 

Continuum 

Atmosphere 

Continuum 

Atmosphere 

Table  1 .  Aerodynamics  Analysis  Tools  Comparison 


This  suite  of  aerodynamic  tools  can  be  used  for  aerodynamic  surface  design  and  to  create 
a  total  aero-  thermodynamic  profile  for  trajectory  and  structural-TPS  analysis.  Pre  and 
post  processing  of  aero  thermal  data  for  structural  and  thermal  analysis  and  for  displayin'^ 
the  results  can  be  interfaced  through  PATRAN.  ° 
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Missile  Datcom 


Missile  DATCOM  is  an  Air  Force  aerodynamic  analysis  code  for  a  limited  range  of  axis- 
symmetric  and  elliptical  body  missile  configurations  with  multiple  sets  of  lifling/control 
surfaces.  This  code  uses  slender  body  theory  mixed  with  semi-empirical  methodology  to 
rapidly  produce  aerodynamic  characteristics  for  subsonic,  transonic,  supersonic  and 
hypersonic  flight  conditions.  A  key  feature  that  has  become  very  useful  is  the  capability 
to  input  experimental  component  data  (e.g.,  body,  body- wing,  body-tail)  that  is  used  in 
place  of  that  component’s  code-calculated  data. 

Inputs  are  very  simple  geometry  (especially  as  compared  to  panel  codes),  reference 
quantities  and  desired  flight  conditions.  Outputs  are  3 -dimensional  aerodynamic 
coefficients,  including  trim  characteristics  and  static  and  dynamic  derivatives. 

Missile  DATCOM  was  selected  for  integration  into  the  system  because  of  its  ease  of  use 
and  rapid  and  inexpensive  calculations.  The  problem  encountered  for  screening  vehicles 
is  that  arbitrary  bodies  cannot  be  input  using  the  code’s  geometry  engine.  This  problem 
was  solved  by  also  integrating  an  aerodynamic  panel  code  (PANAIR)  to  compute 
arbitrary  body  characteristics,  processing  its  output  into  Missile  DATCOM  input  format 
as  “experimental”  body  alone  component  data,  then  using  Missile  DATCOM  to  generate 
complete  configuration  characteristics  (a  simple  equivalent  body  of  revolution  is  input  for 
the  Missile  DATCOM  body  geometry).  Use  of  the  more  CPU  intensive  panel  code  for 
the  body  alone  calculations,  serves  to  reduce  tum-around  time  for  the  calculation  of  the 
aerod)mamic  characteristics  and  the  preliminary  screening  of  TAV  configurations. 

During  the  integration  of  Missile  DATCOM,  GUIs  were  developed  for  input  and  output 
processing.  An  algorithm  to  set  up  multiple  runs  of  the  code  to  develop  and  collect  the 
aerodynamic  output  into  coefficient  tables  of  the  appropriate  format  for  direct  input  to 
trajectory  codes  was  also  created  and  implemented. 

For  a  list  of  AML  functionality  available  in  this  module,  please  see  Appendices  2  and  3. 
PANAIR 

Higher-order  panel  methods  offer  the  appropriate  level  of  fidelity  for  force/moment 
analysis  at  acceptable  run  time  for  today’s  engineering  workstation  environment.  The 
work  developed  allows  the  utilization  of  PANAIR  (and  QUADPAN  in  a  later  update)  to 
capture  trends  of  subsonic/transonic/supersonic  pitching  moments  and  drag-due-to-lift. 
Several  other  panel  codes  such  as  VORLAX,  WOODWARD,  APAS-UDP  could  be 
integrated  in  a  similar  methodology  for  developing  panel  models  that  are  sufficiently 
robust  for  reliable  trends  as  the  vehicle  shape  is  varied.  In  addition,  the  team  has 
developed  processes  for  vehicle  trim  analysis  and  drag-due-to-lift  estimation  that  enhance 
the  data  fidelity  of  panel  codes. 

PANAIR  is  a  NASA  aerodynamic  analysis  code  for  arbitrary  three-dimensional 
configurations  in  subsonic  and  supersonic  speed  regimes.  The  code  solves  the  linearized 
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potential  flow  equations  with  a  higher-order  singularity  distribution  of  sources  and 
doublets  over  surface  panels.  In  the  past,  the  geometry  input  to  this  code  has  been  very 
difficult,  particularly  at  wing/body  junctures,  where  it  is  easy  for  the  user  to  leave  a  gap 
between  panels.  The  PANAIR  code  contains  procedures  to  “fix”  these  holes,  but  the 
whole  process  has  been  a  large  drawback.  In  cooperation  with  Lockheed  Marin 
Orlando’s  Missiles  and  Fire  Control  Engineering  Methods  Group,  PANAIR  has  been 
integrated  into  IMD,  where  it  uses  the  geometry  created  within  the  IMD  design 
environment  to  generate  the  surface  elements,  or  paneling,  at  the  push  of  a  button.  This 
paneling  procedure  leaves  no  gaps,  and  the  panel  normal  vectors  are  always  pointed 
outwards  into  the  flow.  The  user  can  change  the  panel  density  and  the  panel-to-network 
relations,  with  the  click  of  the  mouse.  Other  PANAJR  inputs,  such  as  flight  conditions, 
reference  quanfities,  panel  boundary  conditions  and  wakes,  have  been  assembled  into 

user-friendly,  hierarchical  GUIs  that  automatically  appear  when  related  option  buttons  are 
clicked. 


For  a  list  of  AML  functionality  available  in  this  module,  please  see  Appendix  2  and  4. 


4.6.  Integrated  Environment 

The  system  has  been  developed  to  allow  the  user  to  select  which  modules  (and  analyses) 
^e  used  at  any  time.  The  user  can  also  build  models  using  the  various  modules  and  mix 
different  levels  of  analysis.  For  example,  a  first-order  aerodynamic  analysis  could  be 
used  to  provide  loads  for  a  higher-order  structural  analysis. 

TechnoSoft  has  used  the  Phase  11  resulting  software  modules  into  the  underlying 
framework  architecture  for  air  vehicle  design.  This  framework  supports  a  collaborative 
design  environment  for  seamlessly  integrating  various  tools  and  engineering  processes 
from  the  different  disciplines.  Lockheed  Martin  Missiles  and  Fire  Control  in  Orlando  and 
groups  within  the  Air  Vehicles  Directorate  of  the  Air  Force  Research  Labs  are  currently 
using  the  developed  modules  and  architecture  in  several  AML-based  applications. 
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Appendices 


Appendix  1:  Mesh  Surfaces  AML  Documentation 

This  documentation  is  based  on  the  premise  that  the  cross  sections  used  in  these  classes 
are  in  canonical  space  (created  in  the  XY  plane)  and  then  oriented  using  a  reference 
coordinate  system. 


mesh-surface-from-2-closed-cross-sections-class 


[Class] 


Allows  the  user  to  create  a  web  surface  provided  curve- 1 -object  and  curve-2-object. 


Inherit-from: 


(mesh-points-ffom-2-closed-cross-sections-mixin  mesh-surface-ffom-points- 

class) 


Properties: 

curve- 1  -object  first  curve 

curve-2-object  second  curve 

curve- l-point-generation-method  Specify  point  generation  method  for  curve-1,  'equal  'sin  3d- 

point-list<User  provided  coordinates>,  or  parameter-list 

curve-2-point-generation-method  Specify  point  generation  method  for  curve-2,  'equal  'sin  3d- 

point-list<User  provided  coordinates>,  or  parameter-list 

split-curves-into-upper-lower?  flag  to  indicate  whether  to  split  input  curves  into  upper  and  lower 

niunber-of-points-per-cross-section-list  If  input  curves  are  to  be  split  then  the  property  is  a  list 

specifying  the  number  of  points  on  upper  and  lower  curves,  else  it 
is  a  number  specifying  the  number  of  points  along  the  curves. 

number-of-cross-sections  define  the  number  of  intermediate  cross  sections  between  curve- 1- 

object  and  curve-2-object 

intermediate-curves-shape-factor-list  Controls  the  shape  of  the  intermediate  sections  (a 

factor  of  0.0  maintains  the  shape  of  curve- 1-object  and  factor  of 
1.0  maintains  the  shape  of  curve-2-object) 

intermediate-curves-distance-factor-list  Controls  the  position  of  the  intermediate  curves 

between  curve- 1 -object  and  curve-2-object 

path-curve-object  Determines  the  path  the  intermediate  curves  follow  to  get  from  curve- 1- 

object  to  curve-2 -object 
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intermediate-alignment-type  Controls  how  the  intennediate  curves  are  aligned.  0  =  curve- 1- 

object  normal,  1  =  interpolate,  2  ~  follow  path  curve  normal 


x-plus-scaling-curve-object 
x-minus-scaling-curve-object 
y-plus-scaling-curve-obj  ect 
y-minus-scaling-curve-obj  ect 


points  to  the  x-plus  scaling  curves 
points  to  the  x-minus  scaling  curves 
points  to  the  y-plus  scaling  curves 
points  to  the  y-minus  scaling  curves 


The  user  can  query  the  object  for  the  oriented  mesh  points  by  demanding  the  ^*combined- 
points"  from  an  instance  of  MESH-SURF ACE-FROM-2-CLOSED-CROSS-SECTIONS- 
CLASS.  The  points  are  oriented  in  such  a  way  that  the  panel  normals  point  outside. 


mesh-surface-from-closed-cross-sections-class 


[Class] 


Inherit-from: 

(mesh-points-from-closed-cross-sections-mixinmesh-surface-from-points-class) 


Properties: 

cross-sections-list  cross  sections  to  be  meshed. 

number-of-points-per-cross-section-list  Number  of  points  per  cross  section 

number-of-cross-sections-list  Number  of  intermediate  cross  sections 

intermediate-curves-shape-factor-lists  A  list  of  lists  specifying  the  intermediate  shapes 

factors 

intermediate-curves-distance-factor-lists  A  list  of  lists  specifying  the  location  of  the 

intermediate  curves. 

path-curves-list  A  list  of  path  curves.  Or  the  user  can  provide  a  single  path  curve. 

intermediate-alignment-types-list  A  list  defining  the  alignment  types. 

cross-sections-point-generation-methods-list  Define  point  generation  methods  for  curves, 

split-cross-sections-into-upper-lower?  flag  defining  whether  to  split  cross  sections  into 

upper  and  lower. 


x-plus-scaling-curves-list  X-plus  scaling  curves.  Can  be  a  list  or  a  single  curve 
x-mmus-scaling-curves-list  X-minus  scaling  curves.  Can  be  a  list  or  a  single  curve 
y-plus-scaling-curves-list  Y-plus  scaling  curves.  Can  be  a  list  or  a  single  curve 
y-minus-scaling-curves-list  Y-minus  scaling  curves.  Can  be  a  list  or  a  single  curve 
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The  user  can  query  the  object  for  the  oriented  meshed  points  by  demanding  the 
"combined-points"  from  an  instance  of  MESH-SURPACE-FROM-CLOSED-CROSS- 
SECTIONS-CLASS.  The  points  are  oriented  in  such  a  way  that  the  panel  normals  point 
outside. 


mesh-surface-from-2-open-cross-section-segments-class 


[Class] 


This  class  allows  the  user  to  create  mesh  (open)  curve  segments  and  build  surfaces  from 
the  curve  segments. 


Inherit-from: 


(mesh-surface-from-2-open-cross-section-segments-class) 


Properties: 

curve-segment-list-l  An  ordered  list  of  curve  segments 

curve-segment-list-2  An  ordered  list  of  curve  Segments 

curve-segments- 1 -start-points-list  List  of  points  listing  the  start  points  for  segl  in  global  space 

curve-segments-2-start-points-list  List  of  points  listing  the  start  points  for  seg2  in  global  space 

number-of-points-per-curve-segments-Iist  A  list  of  numbers  specifying  the  number  of  sampled 

points  per  segment. 

number-of-cross-sections  Number  of  intermediate  points. 

intermediate-curves-shape-factor-list  A  list  of  factors  defining  the  shape. 

intermediate-curves-distance-factor-list  A  list  of  factors  defining  the  position  of  the 

intermediate  sections. 

path-curve-object  The  path  the  intermediate  curves  follow. 

intermediate-alignment-type  Intermediate  curves  alignment  types.  0  =  curve-segment-list-l 

normal,  1  =  interpolate  2  =  follow  path  curve  normal 

curve-segment-1  -point-generation-method-list  point  generation  method  for  curves  in  curve- 

segment-list-l 

curve-segment-2-point-generation-method-list  point  generation  method  for  curves  in  curve- 

segment-list-2 

x-plus-scaling-curve-object  X-plus  scaling  curve  object 
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x-minuS“Scaling-curve-object  X-minus  scaling  curve  object 
y-plus-scaling-curve-object  Y-plus  scaling  curve  object 
y-minus-scaling-curve-object  Y-minus  scaling  curve  object 


For  the  user  to  get  the  oriented  points  associated  with  this  object  one  needs  to  call  GET- 
SHABP-OBJECTS  passing  an  instance  of  MESH-SURF ACE-FROM-2-OPEN-CROSS- 
SECTION-SEGMENTS-CLASS  as  input.  This  will  return  a  list  of  instances.  The  user 
can  then  demand  the  combined-points  from  the  returned  instances. 


mesh-points-from-open-cross-section-segments-mixin 


[Class] 


Inherit-from: 

(basic-mesh-points-mixin) 


Properties: 

curve-segment-lists  A  list  of  lists  defining  the  curve  segments. 

curve-segments-start-points-lists  A  List  of  lists  of  points  listing  the  start  points  for  seg  in 

global  coord 

number-of-points-per-cross-section-list  A  list  defining  the  number  of  points  per  segments. 

number-of-cross-sections-list  A  list  defining  the  number  of  intermediate  cross  sections. 

intermediate-curves-shape-factor-lists  A  list  of  lists  defining  the  shape  factors. 

intermediate-curves-distance-factor-lists  A  list  of  lists  defining  the  intermediate  curves 

positions. 

path-curves-list  A  list  defining  the  path  curves. 

intermediate-alignment-types-list  A  list  identifying  the  intermediate  curves  alignment  type, 

cross-sections-point-generation-methods-list  A  list  identifying  point  generation  methods 

x-plus-scaling-curves-list  X-plus  scaling  curve.  Can  be  a  list  or  a  single  curve, 
x-minus-scaling-curves-list  X-minus  scaling  curve.  Can  be  a  list  or  a  single  curve, 
y-plus-scaling-curves-list  Y-plus  scaling  curve.  Can  be  a  list  or  a  single  curve, 
y-minus-scaling-curves-list  Y-minus  scaling  curve.  Can  be  a  list  or  a  single  curve. 


Inherit-from: 


(mesh-surface-from-points-class) 


Properties: 


mesh-surface-to-cap-object  The  mesh  surface  to  be  capped. 


open? 

diameter 

flip-normal? 

center-point-coordinates 


A  flag  set  by  the  user  indicating  whether  the  cap  lies  at  the  front  of  the 
meshed  surface  or  at  the  back  of  the  surface.  Used  to  determine  the 
normal. 

Determines  whether  the  cap  is  open  or  closed. 

Diameter  of  cap,  if  cap  is  open. 

Allows  the  user  to  flip  the  cap  normal. 

A  global  coordinate  specifying  where  the  cap  is  closed. 


number-0 f-cross-sections  Number  of  intermediate  curves. 


For  the  user  to  generate  oriented-points  the  user  needs  to  demand  "COMBINED- 
POINTS"  from  an  instance  of  type  MESH-CAP-FROM-CLOSED-MESH-SURFACE- 
CLASS. 


panel-normals-from-mesh-surface-points-class 


[Class] 


This  class  allows  the  user  to  draw  the  mesh-surface  normals. 


Inherit-from: 


(simple-geometry-class) 


Properties: 


mesh-surface 

normals-length 


Mesh  surface 
Normal  length 
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mesh-surface-data-class 

[Class] 

Allows  the  user  to  print  the  mesh  data  in  a  standard  format 


Inherit-ffom: 

(object) 


Properties: 

mesh-sxirface  The  surface  to  get  the  data  from, 

reference-coordinate-system 

The  user  can  define  a  reference  coordinate  system  allowing  the  user  to 
change  the  mesh  point  coordinates  to  reflect  orientation  of  the 
reference  coordinate  system. 

data-format  Mesh  data  can  be  formatted  in  a  'grid  (cross  sections),  or  'panel  format, 

filename  The  name  of  the  mesh  points  data  file 


read-mesh-surface-data-class 


[Class] 


Allows  the  user  to  read  a  mesh  points  data  file,  create  the  geometry,  orient  the  geometry 
and  then  use  an  instance  of  MESH-SURF ACE-DATA-CLASS  to  regenerate  the  mesh 
points  data  file. 


Inherit-fi’om: 

(geom-object) 


Properties: 

filename  Data  filename 

reference-coordinate-system  Specify  a  reference  coordinate  system 


join-box-class 


[Class] 


Allows  the  user  to  merge  separate  curve  loops  in  a  junction  box. 
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Inherit-from: 


(object) 

Properties: 

box-widtli  Junction  box  width 

box-height  Junction  box  height 

box-depth  Junction  box  depth 

loops-to-join  A  list  of  curve  Loops  to  join. 

start-node-number  The  start  node  number 

number-of-loop-points  A  list  of  lists  of  box  faces  and  number  of  points  on  the  face  edges. 

number-of-intermediate-points  Number  of  intermediate  cross  sections  between  the  loops  to  join 

and  the  box  faces 
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Appendix  2:  AML  General  Aerodynamics  Classes 


This  document  covers  the  following  class  types: 

•  Aerodynamic  Coefficient  Sources 

•  Flight  Conditions 


The  aerodynamic  coefficients  source  classes  provide  a  common  interface  for  accessing 
coefficient  data.  Classes  and  applications  can  be  written  using  interfaces  that  are 
independent  of  the  source  of  coefficient  information. 


The  flight  conditions  class  provides  a  standard  way  to  specify  ranges  of  Mach  numbers 
and  flight  angles. 


Aerodynamic  Coefficients  Source  Classes 


These  classes  provide  a  common  interface  that  can  be  used  by  all  classes  which  provide 
aerodynamic  coefficient  data,  whether  that  data  originates  from  analysis,  stored  data  in  a 
file,  or  experimental  data. 


These  classes  assume  that  the  data  can  be  referenced  in  a  multidimensional  tabular  form. 
The  data  is  stored  as  lists  of  coefficient  values  and  referenced  by  key  values.  The 
coefficients  can  be  anything,  but  are  typically  quantities  such  as  lift  and  drag  coefficients. 
The  keys  are  typically  Mach  numbers,  angles  of  attack,  etc.  It  is  assumed  that  the  data 
will  be  for  ranges  of  key  values  (e.g.,  for  Mach  numbers  0.5,  0.6,  0.7,  and  0.8)  and  that  all 
combinations  of  key  values  will  have  corresponding  coefficients. 


The  classes  which  provide  this  capability  are  aerodynamic-coefficients-source-class  and 
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file-aerodynamic-coefficients-source-class.  The  class  aerodynamic-coefficients-plot- 
class  provides  a  way  to  present  a  graphical  representation  of  the  data  contained  in  a  class 
that  inherits  from  aerodynamic-coefficients-source-class. 


aerodynamic-coefficients-source-class 


[Class] 


This  class  is  used  to  provide  a  common  interface  for  other  classes  that  compute 
aerodynamic  coefficients.  By  combining  this  class  with  a  class  that  computes  the 
coefficients,  any  other  class  can  access  those  coefficients  using  common  properties  and 
methods.  This  allows  classes  that  require  aerodynamic  coefficients  to  be  written  without 
needing  specific  knowledge  about  the  originating  classes. 


This  class  stores  a  multidimensional  table  of  data.  The  data  in  the  table  is  referenced  by 
keys.  These  keys  refer  to  things  like  Mach  number  or  angle  of  attack.  For  each 
combination  of  key  values,  a  set  of  coefficients  can  be  retrieved  from  the  table  (if  those 
key  values  are  valid). 


This  class  is  typically  used  to  provide  access  to  coefficients  that  were  generated  by 
computing  values  for  all  possible  combinations  of  key  values  (i.e.,  by  looping  through 
lists  of  Mach  numbers,  angles  of  attack,  etc.,  and  computing  coefficients  for  each 
combination). 


The  keys  and  coefficients  have  associated  symbols,  labels,  and  descriptions.  The  symbol 
is  a  single-quoted  name  for  the  key  or  coefficient  (e.g.,  'M  for  Mach  number).  The 
symbol  is  used  for  all  reference  to  values  of  the  key  or  coefficient.  The  label  is  a  short 
string  used  to  refer  to  the  key  or  coefficient  (e.g.,  "M"  for  Mach  number).  The  label  is 
used  for  short  references.  The  description  is  a  longer  string  used  to  refer  to  the  key  or 
coefficient  (e.g.,  "Mach  Number").  The  description  might  be  used  in  the  labels  for  a 
graph  or  table. 


Example  user-specified  property  values: 
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Property 

Example  Value 

ac-key-symbols 

'(M  alpha  beta) 

ac-key-ranges 

'((0.5  0.7  0.9  1.1  1.3)  (0.0  5.0  lO.O)  (0.0  2.0  4.0)) 

ac-key-labels 

'("M"  "alpha"  "beta") 

ac-key-descriptions 

'("Mach  Number"  "Angle  of  Attack"  "Sideslip 
Angle") 

ac-coefficient-symbols 

'(CA  CY  CN  CSL  CSM  CSN) 

The  internally  recognized  coefficients  are  summarized  in  the  following  table.  When  the 
user  specifies  coefficients  in  ac-coefficient-symbols,  the  values  in  this  table  will  be  used 
to  fill  in  the  property  ac-coefficient-info.  The  coefficients  do  not  need  to  be  restricted  to 
those  available  in  this  table.  If  other  coefficients  are  specified,  either  ac-coefficient-info 
will  need  to  be  overridden  or  the  default  values  (using  the  symbol  as  label  and 
description)  will  be  used. 


Coefficient 

Symbol 

Coefficient  Label 

Coefficient  Description 

CN 

"CN" 

"Normal  Force  Coefficient" 

CSM 

"Cm" 

"Pitch  Moment  Coefficient" 

CA 

"CA" 

"Axial  Force  Coefficient" 

CY 

"CY" 

"Side  Force  Coefficient" 

CSN 

"Cn" 

"Yaw  Moment  Coefficient" 

CSL 

"Cl" 

"Roll  Moment  Coefficient" 

CSMA 

"Cma" 

"dCm/dalpha" 

CAN 

"CNa" 

"dCN/dalpha" 
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CSNB 

"Cnb" 

"dCn/dbeta" 

CYB 

"CYb" 

"dCY/dbeta" 

CSLB 

"CIb" 

"dCl/dbeta" 

CLCD 

"CL/CD" 

"CL/CD" 

XCP 

"Xcp" 

"Center  of  Pressure" 

CL 

"CL" 

"Lift  Coefficient" 

CD 

"CD" 

"Drag  Coefficient" 

The  coefficient  data  in  this  class  should  be  accessed  through  the  get-coefficients  method. 


Inherit-ffom: 

(multi-key-table-class) 


Properties: 


ac-key-symbols 
ac -coefficient-symbols 
ac-key-ranges 

ac-key-labels 

ac-key-descriptions 

ac-possible-coefficients 


ac-coefficient-info 


A  list  of  symbols  used  to  refer  to  key  values  in  table. 

A  list  of  symbols  used  to  refer  to  coefficients  in  the  table, 

A  list  of  lists  containing  the  values  corresponding  to  each  key  in  the 
table. 

A  list  of  short  strings  corresponding  to  each  symbol  in  ac-key-symbols. 

A  list  of  strings  providing  descriptions  of  each  symbol  in  ac-key’- 
symbols. 

This  property  contains  a  list  of  lists  of  data  providing  default  coefficient 
information.  The  contents  of  this  list  are  summarized  in  the  table 
above.  This  property  should  normally  not  be  changed  by  the  user. 

This  property  contains  a  list  of  lists  of  information  describing  the 

coefficients  listed  in  ac-coefficient-symbols .  This  property  should 
normally  not  be  changed  by  the  user.  This  list  will  contain  lists  of 
(symbol  label  description)  for  each  coefficient  automatically 
created  from  the  information  in  ac-possible-coefficients.  The  label 
and  description  will  be  string  versions  of  the  coefficient  symbol  for 
all  symbols  not  available  in  ac-possible-coefficients . 
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The  following  example  class  will  be  used  to  illustrate  the  methods  that  access  the 
properties  and  data  in  this  class.  For  the  examples,  assxnne  that  an  instance  of  this  class 
has  been  created  and  can  be  referenced  as  Icoeffs. 


(define- cl  ass  example-aero-coef  f  s-class 

:  inherit-f rom  (aerodynamic-coef ficients-source-class ) 
.’properties  { 


ac- key-symbols 
ac-key-ranges 
ac-key-labels 
ac- key-descriptions 


ac-coef ficient-symbols  ’ (CA  CY  CN) 


' (M  alpha  beta) 

'({0.5  0.7  0.9)  (0.0  5.0  10.0)  (0.0  2.0)) 

I  "alpha"  "beta") 

' ("Mach  Number"  "Angle  of  Attack"  "Sideslip  Angle") 


;The  data  in  table-list  would  normally  be  generated  by  an  analysis  class. 
; It  is  set  directly  in  this  example  for  illustration  purposes  only. 


(  (  (0.5 

0.0 

0.0) 

(0.0 

0.1 

0.2)) 

(  (0.5 

0.0 

2.0) 

(0.3 

0.4 

0.5)  ) 

(  (0.5 

5.0 

0.0) 

(0.6 

0.7 

0.8)  ) 

((0.5 

5,0 

2.0) 

(0.9 

1.0 

l.D) 

(  (0.5 

10,0 

0.0) 

(1.2 

1.3 

1.4)  ) 

({0.5 

10.0 

2.0) 

(1.5 

1.6 

1.7)) 

((0.7 

0.0 

0.0) 

(1.8 

1.9 

2.0)  ) 

(  (0.7 

0.0 

2.0) 

(2.1 

2.2 

2.3)  ) 

(  (0.7 

5.0 

0.0) 

(2.4 

2.5 

2.6)  ) 

(  (0.7 

5.0 

2.0) 

(2.7 

2.8 

2.9)  ) 

(  (0.7 

10.0 

0.0) 

(3.0 

3.1 

3.2)  ) 

(  (0.7 

10.0 

0.0) 

(3.3 

3.4 

3.5)) 

(  (0.9 

0.0 

0.0) 

(3.6 

3.7 

3,8)  ) 

((0.9 

0.0 

2.0) 

(3.9 

4.0 

4.1)  ) 

(  (0.9 

5.0 

0.0) 

(4.2 

4.3 

4.4)  ) 

(  (0.9 

5.0 

2.0) 

(4.5 

4.6 

4.7)  ) 

(  (0.9 

10.0 

0.0) 

(4.8 

4.9 

5.0)  ) 

(  (0.9 

10.0 

2.0) 

(5.1 

5.2 

5.3)  ) 

) 


) 


) 


get-key-range  aerodynamic-coefficients-source-class 


[Method] 


This  method  returns  the  range  of  values  for  any  of  the  keys. 


Format: 


(get-key-range  instance  symbol) 


Arguments: 

instance  An  instance  of  the  class  aerodynamic-coefficients-source-class. 

symbol  A  symbol  representing  one  of  the  keys  to  the  data  table. 
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Examples: 

(get-key-range  Icoeffs  ’M)  returns  '(0.5  0.7  0.9) 
(get-key-range  !  coef  f  s  '  B)  returns  nil  since  'B  is  not  a  key  for  this  data. 


get-coefficients  aerodynamic-coefficients-source-class 


[Method] 


This  method  should  be  used  to  access  coefficient  data  in  the  aerodynamic-coejficient- 
sources-class. 


This  method  returns  a  list  of  coefficients  for  specified  key  values.  The  key-info  argument 
allows  the  user  to  request  coefficient  values  for  any  combination  of  key  values.  The 
coefficients  argument  allows  the  user  to  request  specific  coefficients  only. 


The  information  is  returned  in  the  form  of  a  list  of  lists.  Each  entry  in  the  list  contains  a 
list  of  key  values  (in  the  order  given  in  key-info)  and  a  list  of  coefficient  values  (in  the 
order  given  in  coefficients). 


Format: 


(get-coefficients  instance  key-info  coefficients) 


Arguments: 

instance 

key-info 


coefficients 


An  instance  of  the  class  aerodynamic-coefficients-source-class. 

A  list  of  lists  containing  key  symbols  and  values.  Coefficients  which 
have  keys  with  the  specified  values  will  be  returned.  In  the  results, 
the  key  values  will  be  returned  in  the  same  order  as  specified  in 
key-info.  A  range  of  nil  indicates  that  all  values  in  the  table  for  that 
key  should  be  returned. 

A  list  of  requested  coefficient  symbols.  The  coefficients  will  be 
returned  in  the  same  order. 


Examples: 
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(get-coefficients  Icoeffs  ' ( (M  (0.5))  (alpha  (5.0))  (beta  (0.0))) 

'  (CA)  )  returns  (((0.5  5.0  0.0)  (0.6))) 


(get-coefficients  Icoeffs  '  (  (M)  (alpha)  (beta))  '  (CA)  )  returns  CA  for 

all  values  of  'M,  'alpha,  and  'beta:  '(((0.5  0.0  0.0) 

(0.0)  )  ...  (  (0.9  10.0  2.0)  (5.1)  )  ). 

(get-coefficients  Icoeffs  ' ( (M  (0.5))  (alpha  (0.0  5.0))  (beta 

(0.0)))  '  (CA)  )  returns  ((  (0.5  0.0  0.0)  (0.0)) 

( (0.5  5.0  0.0)  (0.6) ) ). 

(get-coefficients  Icoeffs  ' ( (M  (0.5))  (alpha  (0.0))  (beta  (2.0))) 

'  (CA  CN  CY)  )  returns  (((0.5  0.0  2.0)  (0.3  0.5 

0.4)  )  ) 


write-coefRcients-file  aerodynamic-coefficients-source-class  [Method] 

This  method  is  used  to  write  the  data  contained  in  the  aerodynamic-coefficients-source- 
class  object  to  a  file  in  a  standard  format.  This  format  is  common  between  all  classes  that 
inherit  from  aerodynamic-coefficients-source-class.  Objects  or  applications  written  to 
read  this  format  will  be  able  to  read  data  form  any  of  these  classes. 


Format: 


(write-coef f icientS“f ile  instance  filepath  : coefficients ) 


Arguments: 

instance 

filepath 

rcoefficients 


An  instance  of  the  class  aerodynamic-coefficients-source-class. 

The  full  path  and  file  name  of  the  data  file. 

This  argument  allows  the  user  to  override  the  coefficient  data  that 

would  normally  be  written.  The  default  value  is  nil  and  this  should 
not  normally  be  changed. 


read-coefficients-file  aerodynamic-coefficients-source-class  [Method] 

This  method  is  used  to  read  key  and  coefficient  data  from  a  file  written  in  the  standard 
format  (see  the  method  write-coefficients  file).  This  method  returns  a  list  of  data  -  it  does 
not  directly  change  the  object.  This  method  is  used  by  file-aerodynamic-coefficients-file 
to  retrieve  data. 


Format: 


29 


(read-coefficients-file  instance  filepath) 


Arguments: 

instance 

filepath 


An  instance  of  the  class  aerodynamic-coefficients-source-class, 
The  fiill  path  and  file  name  of  the  data  file. 


gGnerate-coefficients-file  aerodynamic-coefficients-source-class  [Method] 

This  method  is  used  to  write  the  data  contained  in  the  derodynamic-coejficients-soiirce- 
class  object  to  a  stream  in  a  standard  file  fomiat.  This  file  format  is  common  between  all 
classes  that  inherit  from  aerodynamic-coefficients-source-class.  Objects  or  applications 
written  to  read  this  format  will  be  able  to  read  data  from  any  of  these  classes.  This 

method  is  called  from  within  write-coefficients-file,  which  can  be  used  to  write  the  data 
directly  to  a  file. 


Format: 


(gsneratiB  coGf  f  icients-f  ile  instance  :  stream  ;  version 

: coefficients ) 


Arguments: 

instance 
:  stream 

:version 

icoefficients 


An  instance  of  the  class  aerodynamic-coefficieiits-soiirce-class. 

A  keyword  specifying  the  stream  that  the  data  should  be  written  to.  The 
default  value  of  t  will  write  the  data  to  the  AML  buffer. 

Specifies  the  file  version  that  should  be  written.  This  will  default  to  the 
latest  version  and  should  not  normally  be  specified. 

This  argument  allows  the  user  to  override  the  coefficient  data  that 

would  normally  be  written.  The  default  value  is  nil  and  this  should 
not  normally  be  changed. 


g6nerat6“Vi6W“C0effici6nts-tabl6  aerodynamic-coefficients-source-class 


[Method] 


This  method  is  used  to  create  a  tabular  report  of  the  data  contained  in  the  aerodynamic- 

coefficients-source-class.  This  is  primarily  available  to  provide  an  easily  human-readable 
report  format. 


Format: 
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(generate-view-coef ficients-table  instance  : stream) 


Arguments: 

instance  An  instance  of  the  class  aerodynamic-coefficients-source-class. 

istream  A  keyword  specifying  the  stream  that  the  output  should  be  written  to. 

The  default  value  of  t  will  write  the  data  to  the  AML  buffer. 


file-aerodynamic-coefficients-source-class 


[Class] 


This  class  provides  an  interface  to  aerod3mamic  coefficient  data  that  is  contained  in  a  file 
written  in  the  standard  format  (i.e.,  by  the  method  write-coefficients-jile).  Normally,  this 
will  be  data  that  was  created  in  another  instance  of  a  class  inheriting  from  aerodynamic- 
coefficients-source-class. 


To  any  other  objects  using  the  standard  access  methods  (e.g.,  get-coefficients),  this  object 
will  appear  the  same  as  the  object  where  the  data  originated. 


This  class  may  also  be  used  to  provide  an  interface  to  externally  created  data  (e.g., 
experimental  data)  which  has  been  written  to  a  file  in  the  correct  format. 


Inherit-from: 

(aerodynamic-coeffrcients-source-class) 


Properties: 

filepath  The  full  path  and  file  name  of  the  data  file. 

file-info  This  property  contains  information  on  the  data  in  the  file.  It  should  not 

normally  be  accessed  by  the  user  and  should  not  be  changed.  The 
normal  aerodynamic-coefficients-source-class  properties  should  be 
used  to  access  the  data. 


31 


aerodynamic-coefficients-plot-class 

[Class] 

This  class  provides  an  x-y  plot  of  the  coefficient  data  contained  in  an  instance  of 
aerodynamic-coefficient-source-class. 


The  data  can  be  plotted  as  lines  of  constant  Mach  number,  constant  angle  of  attack,  or 
both.  The  values  of  the  keys  other  than  'M  and  'alpha  must  be  constant  for  the  plot  and 
are  set  in  the  property  other-key-values. 


The  appearance  of  the  plot  can  be  modified  by  changing  the  datagraph-object  properties 
that  are  inherited  into  this  class. 


hiherit-from: 

(datagraph-obj  ect) 


Properties: 

coefficients-obj  ect 
ordinate-symbol 

abscissa-symbol 

show-mach-curves? 

show-alpha-curves? 

other-key-values 


title-prefix 


This  property  should  contain  a  reference  to  an  instance  oi  aerodynamic- 
coefficien  t-source-class . 

The  symbol  of  the  key  or  coefficient  which  should  be  used  as  the  y-axis 
of  the  plot.  This  symbol  must  be  present  in  either  the  ac-key- 
symbols  or  ac-coefficient-symbols  property  of  the  coefficients- 
object. 

The  symbol  of  the  key  or  coefficient  which  should  be  used  as  the  x-axis 
of  the  plot.  This  symbol  must  be  present  in  either  the  ac-key- 
symbols  or  ac-coeffiicient-symbols  property  of  the  coefficients- 
object. 

When  t,  lines  of  constant  Mach  number  will  be  plotted.  The  default 
value  is  t. 

When  lines  of  constant  angle  of  attack  will  be  plotted.  The  default 
value  is  t. 

A  list  of  values  for  keys  other  than  'M  and  'alpha.  These  will  be  held 
constant  in  the  plot.  The  order  of  the  values  corresponds  to  the 
order  of  the  keys  in  other-keys.  The  default  values  will  be  the  first 
entries  in  ac-key-ranges. 

A  string  value  in  this  property  will  be  used  as  the  beginning  of  the  title 
displayed  at  the  top  of  the  graph.  The  default  value  is  nil  and 
indicates  that  no  additional  title  text  will  be  included.  The  title  will 
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be  constructed  from  this  property  and  the  contents  of  plot- 
description. 

key-symbols  A  local  copy  of  the  property  ac-key-symbols  in  coefficients-object. 

This  should  not  be  changed  by  the  user. 

coefficient-symbols  A  local  copy  of  the  property  ac-co efficient-symbols  in  coefficients- 

object.  This  should  not  be  changed  by  the  user. 

mach-index  The  position  of  the  Mach  number  symbol  in  the  list  ac-key-ranges. 

This  should  not  be  changed  by  the  user. 

alpha-index  The  position  of  the  angle  of  attack  symbol  in  the  list  ac-key-ranges. 

This  should  not  be  changed  by  the  user. 

mach-numbers  The  range  of  Mach  numbers  in  ac-key-ranges.  This  should  not  be 

changed  by  the  user. 

angles-of-attack  The  range  of  angles  of  attack  in  ac-key-ranges.  This  should  not  be 

changed  by  the  user. 

other-keys  A  list  of  keys  other  than  'M  (Mach  number)  and  'alpha  (angle  of  attack) 

in  coefficients-object.  This  should  not  be  changed  by  the  user. 

ac-key-descriptions  A  local  copy  of  the  property  ac-key-descriptions  in  coefficients-object. 

This  should  not  be  changed  by  the  user. 

ac-key-ranges  A  local  copy  of  the  property  ac-key-ranges  in  coefficients-object.  This 

should  not  be  changed  by  the  user. 

key-search-list  A  list  containing  the  key  info  required  to  get  coefficients  from 

coefficients-object.  This  should  not  be  changed  by  the  user. 

coefficients-list  The  results  of  a  call  to  get-coefficients  on  coefficients-object.  This 

should  not  be  changed  by  the  user. 

variable-labels  A  list  of  labels  for  all  keys  and  coefficients  in  coefficients-object.  This 

should  not  be  changed  by  the  user. 

variable-descriptions  A  list  of  descriptions  for  all  keys  and  coefficients  in  coefficients-object. 

This  should  not  be  changed  by  the  user. 

variable-label-descriptions  A  list  of  combined  variable-labels  and  variable-descriptions.  This 

should  not  be  changed  by  the  user. 

mach-lists  A  list  of  data  used  to  draw  constant  Mach  lines  in  the  plot.  This  should 

not  be  changed  by  the  user. 

alpha-lists  A  list  of  data  used  to  draw  constant  angle  of  attack  lines  in  the  plot. 

This  should  not  be  changed  by  the  user. 

ordinate-index  The  position  of  the  ordinate-symbol  in  the  key-symbols  list.  This 

should  not  be  changed  by  the  user. 

abscissa-index  The  position  of  the  abscissa-symbol  in  the  key-symbols  list.  This 

should  not  be  changed  by  the  user. 

mach-curves  A  list  of  data  used  to  draw  constant  Mach  lines  in  the  plot.  This  should 

not  be  changed  by  the  user. 

alpha-curves  A  list  of  data  used  to  draw  constant  angle  of  attack  lines  in  the  plot. 

This  should  not  be  changed  by  the  user. 

data  The  data  that  is  drawn  in  the  plot:  a  combination  of  mach-curves  and 

alpha-curves  as  appropriate.  This  should  not  be  changed  by  the 
user. 


multi-key-tabie-class  _ [Class] 

This  class  provides  basic  functionality  for  maintaining  a  set  of  data  in  a  table-lookup 
form.  When  using  an  instance  of  aerodynamic-coefficients-source-class^  the  access 
methods  associated  with  that  class  should  be  used  instead  of  those  associated  with  multi¬ 
key-table-class. 


33 


Inherit-firom: 


(object) 


Properties; 

table-list 


This  property  contains  key-referenced  data.  It  should  not  normally  be 
changed  or  accessed  by  the  user.  The  methods  add-record-to-table 
and  get-records-from-table  should  be  used. 


add-record-to-table  multi-key-table-class 


[Method] 


This  method  is  used  to  add  data  to  an  instance  of  multi-key-table-class. 


Forniat: 


(add  record  to-table  instance  keys  value) 


Arguments: 

instance 

keys 

value 


An  instance  of  the  class  multi-key-table-class. 

A  list  of  the  key  values  for  the  record  being  added  to  the  object  data. 
A  list  of  the  value  associated  with  the  keys  that  is  being  added  to  the 
object  data. 


get-records-from-table  multi-key-table-class 


[Method] 


This  method  is  used  to  retrieve  one  or  more  records  from  an  instance  of  multi-key-table- 
class.  All  records  which  match  the  specified  keys  will  be  returned. 


Format: 


(get  records  from— table  instance  keys) 
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Arguments: 

instance  An  instance  of  the  class  multi-key-table-class. 

keys  A  list  of  lists  of  key  values  for  records  which  should  be  retrieved  from 

the  object.  All  records  that  match  the  values  specified  will  be 
returned. 


Flight  Conditions  Class 

flight-conditions-class 

fClassl 

This  class  is  used  to  specify  a  range  of  flight  conditions  that  can  be  used  as  input  to  other 
objects  primarily  analysis  classes).  Typically,  by  pointing  to  an  instance  of  this  class, 
these  objects  will  automatically  get  Mach  number  and  angle  information.  The  analysis 
objects  will  then  compute  values  (primarily  aerodynamic  coefficients)  for  each  possible 
combination  of  Mach  number  and  the  angles.  This  behavior  is  from  the  analysis  object  - 
th.Qflight-conditions-class  is  only  used  to  specify  input  data. 


This  class  has  properties  for  two  different  modes  for  specifying  flight  angles.  The  mode 
is  indicated  by  the  property  angle-mode.  When  angle-mode  is  'body-axes,  then  the 
properties  angles-of-attack  and  sideslip-angles  should  be  used  to  specify  a  range  of  angles 
of  attack  and  sideslip  angles.  When  angle-mode  is  'total,  then  the  properties  total-angles- 
of-attack  and  roll-angles  should  be  used  to  specify  a  range  of  total  angles  of  attack  and 
roll-angles. 


Some  classes  which  use  a  reference  to  an  instance  of flight-conditions-class  as  an  input 
may  not  be  able  to  use  both  modes  of  flight  angle  specification. 


Inherit-from; 

(object) 


Properties: 

mach-numbers  A  list  of  Mach  numbers.  The  default  value  is  «//. 

angle-mode  This  property  specifies  which  angle  properties  contain  flight  condition 

information.  Allowed  values  are  'body-axes  and  'total.  When 
angle-mode  is  'body-axes,  the  properties  angles-of-attack  and 
sideslip-angles  should  be  used.  When  angle-mode  is  'total,  the 
properties  total-angles-of-attack  and  roll-angles  should  be  used. 
The  default  value  is  'body-axes. 

angles-of-attack  A  list  of  angles  of  attack  to  be  used  when  angle-mode  is  'body-axes. 

The  default  value  is  nil. 
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sideslip-angles 

total-angles-of-attack 

roll-angles 


A  list  of  sideslip  angles  to  be  used  when  angle-mode  is  'body-axes.  The 
default  value  is  nil. 

A  Ust  of  total  angles  of  attack  to  be  used  when  angle-mode  is  'total. 

The  default  value  is  nil, 

A  list  of  roll  angles  to  be  used  when  angle-mode  is  'total.  The  default 
value  is  nil. 


Appendix  3:  AML/Datcom  Interface  Documentation 


The  datcom-source-class  provides  the  primary  interface  to  the  Datcom  application. 
Control  of  Datcom  is  through  properties  in  this  object  and  in  its  children.  Additional 
objects  may  need  to  be  instantiated  to  interface  to  the  vehicle  geometry. 


All  of  the  capabilities  of  this  interface  to  Datcom  can  be  accessed  through  properties. 
Users  will  normally  not  need  to  call  any  methods. 


datcom-source-class 


[Class] 


The  datcom-source-class  provides  an  AML  interface  to  Datcom. 


Several  of  the  properties  of  this  class  are  used  to  point  to  instances  of  other  classes.  The 
flight-conditions-object  pxoyQvty  should  point  to  an  instance  of  c\2iss  flight-conditions- 
class.  If  this  property  is  given  a  value  of  nil,  then  the  user  must  provide  values  for  the 
flight  condition  properties  (flight-conditions-angle-mode,  total-angles-of-attack,  roll- 
angles,  angles-of-attack,  sideslip-angles,  and  mach-numbers)  as  required  (see  X]\q  flight- 
conditions-angle-mode  for  property  requirements). 


Depending  on  the  values  given  to  some  of  the  properties  of  this  object,  more  than  one  run 
of  Datcom  may  be  required.  This  is  handled  transparently  by  the  class;  no  user 
interaction  or  special  setup  is  required. 


The  datcom-source-class  has  several  subobjects,  some  of  which  have  properties  that 
should  be  changed  by  the  user.  In  order  to  change  the  values  or  formulas  of  these 
properties,  new  classes  will  need  to  be  created  (inheriting  from  the  originals)  with 
replacement  formulas  and  put  in  the  subobjects  section  of  a  new  datcom  class  inheriting 
from  datcom-source-class.  The  subobjects,  their  classes,  and  whether  they  contain  user- 
editable  properties  are  summarized  in  this  table; 
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Subobject  Name 

Subobject  Class 

User 

Editable? 

fltcon 

datcom-fltcon-class 

yes 

refq 

datcom-refq-class 

yes 

trim 

datcom-trim-class 

yes 

fmsets 

datcom-finset-properties-class 

no 

body 

datcom-body-properties-class 

no 

protuberances 

datcom-protuberance-set-properties- 

class 

no 

inlet 

datcom-inlet-properties-class 

no 

This  table  summarizes  the  keys  used  to  access  the  results  of  Datcom  runs. 


Table  Key 

ac-key- 

symbols 

ac-key- 

labels 

ac-key-descriptions 

Included  when  flight- 
conditions-angle-mode 
is 

Mach 

number 

"M" 

"Mach  Number" 

angle  of 

attack 

'alpha 

"alpha" 

"Angle  of  Attack" 

'body-axes 

sideslip 

angle 

'beta 

"beta" 

"Sideslip  Angle" 

'body-axes 

total  angle 
of  attack 

'alpha-t 

"alpha-t" 

"Total  Angle  of 
Attack" 

'total 

roll  angle 

'phi 

"phi" 

"Roll  Angle" 

'total 

deflection 

'(delta 

'("delta" 

'("Control 

info 

wing-set 

"wing-set" 

Deflection" 

"Wing  Set  Number" 

wing) 

"wing") 

"Wing  Number") 

This  table  summarizes  the  coefficients  that  are  computed  by  Datcom  and  stored  in  this 
object.  Coefficients  are  included  only  when  their  associated  property  is  t. 


Coefficients 

Included  when 

CN  CSM  CA  CY  CSN  CSL  CSMA 
CAN  CSNB  CYB  CSLB  CLCD  XCP  CL 
CD 

always 

CMQ  CLNR  CLLP 

compute-dynamic- 

derivatives? 

CAP 

include-power-on-data? 

CNT  CAT  CLT  CDT 

include-trim-power-off- 

data? 

CAPT  CDPT 

include-trim-power-on- 

data? 

Inherit-From: 


(aerodynamic-coefficients-source-class) 


Properties: 

flight-conditions-object  The  value  of  this  property  should  be  a  t/ie-reference  to  an  instance  of 

class  flight-conditions-class.  The  datcom-source-class  object  will 
get  values  from  the  following  properties  from  this  object:  flight- 
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conditions-angle-mode,  total-angles-of-attack,  roll-angles,  angles- 
of-attack,  sideslip-angles,  and  mach-numbers. 


flight-conditions-angle-mode  The  orientation  of  the  vehicle  can  be  specified  using  either  the 

body  axes  angles  or  total  angles.  If  the  value  is  'body-axes,  then 
the  properties  angles-of-attack  and  sideslip-angles  must  be  given 
values.  If  the  value  is  'total,  then  the  properties  total-angles-of- 
attack  and  roll-angles  must  be  given  values.  If^heflight- 
property  points  to  an  instance  of flight- 
conditions-class,  then  the  value  of flight-conditions-angle-mode 
will  be  taken  from  that  object.  Allowable  values  for  flight- 
conditions-angle-mode  are  'body-axes  and  'total. 
total-angles-of-attack  If  the  flight-conditions-object  property  does  not  point  to  aflight- 

conditions-class  object  and  the  flight-conditions-angle-mode 
property  has  a  value  of  'total,  then  this  property  should  contain  a 
list  of  the  total  angles  of  attack  (in  degrees)  for  which  aerodynamic 
coefficients  should  be  computed  (e.g.,  '(0.0  5.0  10.0  15.0). 
roll-angles  If  the  flight-conditions-object  property  does  not  point  to  z.flight- 

conditions-class  object  and  the  flight-conditions-angle-mode 
property  has  a  value  of  'total,  then  this  property  should  contain  a 
list  of  the  roll  angles  (in  degrees)  for  which  aerodynamic 
coefficients  should  be  computed  (e.g.,  '(0.0  2.0  4.0  6.0). 
angles-of-attack  If  the  flight-conditions-object  property  does  not  point  to  aflight- 

conditions-class  object  and  the  flight-conditions-angle-mode 
property  has  a  value  of  'body-axes,  then  this  property  should 
contain  a  list  of  the  angles  of  attack  (in  degrees)  for  which 
aerodynamic  coefficients  should  be  computed  (e.g.,  '(0050  100 
15.0). 

sideslip-angles  If  the  flight-conditions-object  property  does  not  point  to  aflight- 

conditions-class  object  and  the  flight-conditions-angle-mode 
property  has  a  value  of  'body-axes,  then  this  property  should 
contain  a  list  of  the  sideslip  angles  (in  degrees)  for  which 
aerodynamic  coefficients  should  be  computed  (e.g.,  '(002040 
8.0). 


mach-numbers 


If  the  flight-conditions-object  property  does  not  point  to  aflight- 
conditions-class  object,  this  property  should  contain  a  list  of  the 
Mach  numbers  for  which  aerodynamic  coefficients  should  be 
computed  (e.g.,  '(0.5  0.6  0.8  0.9  1.1  1.2)). 


fuselage-interface-object  This  property  should  point  to  an  instance  of  datcom-fuselage-interface- 

class.  This  object  contains  information  required  to  create  the 
Datcom  input  for  the  fuselage. 

wmg-set-geometry-objects  This  property  should  contain  a  list  of  instances  of  datcom-wing-set- 

interface-class.  Each  of  these  instances  will  contain  information 
required  to  create  the  Datcom  input  data  for  wings  or  fins, 
promberance-set-source-object  This  property  should  point  to  a  datcom-protuberances-interface- 

class.  This  object  contains  information  required  to  create  the 
Datcom  input  for  protuberances. 

inlet-source-object  This  property  should  point  to  a  datcom-inlet-interf ace-class.  This 

object  contains  information  required  to  create  the  Datcom  input  for 
the  promberance. 


umts-for-datcom-run  Determines  the  umts  of  the  data  being  given  to  and  coming  out  of 

Datcom.  Allowed  values  are  'in  'ft  'em 'm.  The  default  value  is  'in. 

data-directory  The  directory  in  which  foe  output  of  foe  datcom-source-class  object 

should  be  written.  The  default  is  (logical-path  :temp). 
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results-file 


The  path  and  filename  where  the  aerodynamic  coefficients  from  the 
Datcom  mns  should  be  stored.  The  default  file  has  the  name 
"coeffs.dat”  and  will  be  written  to  the  directory  given  by  the 
property  data-directoiy. 

log-file  The  path  and  filename  where  a  record  of  the  Datcom  runs  and  output 

files  should  be  stored.  The  default  file  has  the  name  ’’datcom.log" 
and  will  be  written  to  the  directory  given  by  the  property  data- 
directory. 

output-directory  The  directory  in  which  the  actual  output  files  from  Datcom  should  be 

written.  Sequentially  numbered  copies  of  several  of  the  output  files 
will  be  kept  in  this  directory  (and  logged  in  the  file  given  by  the 
property  log-file).  By  default,  this  is  the  same  directory  as  that 
given  in  the  property  data-directoiy. 

compute-dynamic-derivatives?  If  the  values  of  the  dynamic  derivatives  (CMQ,  CLNR,  CLLP) 

will  be  computed.  If  nil,  no  dynamic  derivatives  will  be  computed. 

include-power-on-data?  If  /,  an  additional  aerodynamic  coefficient  will  be  computed  for  the 

power  on  case  (CAP).  If  nil,  this  coefficient  will  not  be  computed. 

include-trim-power-on-data?  If  t,  additional  aerodynamic  coefficients  will  be  computed  for  the 

power  on  trim  condition  (CAPT,  CDPT).  If  nil,  no  additional 
coefficients  will  be  computed. 

include-trim-power-off-data?  If  t,  additional  aerodynamic  coefficients  will  be  computed  for  the 

power  off  trim  condition  (CNT,  CAT,  CLT,  CDT).  If  nil,  no 
additional  coefficients  will  be  computed. 

run-fin-de flections?  If  t,  additional  Datcom  runs  will  be  made  to  determine  the  aerodynamic 

coefficients  for  a  range  of  fin  deflections.  The  deflections  are 
given  by  the  wing  or  fin  interface  objects. 

show- window- wlhle-running?  If  t,  a  window  indicating  that  Datcom  is  running  may  be  displayed. 

The  default  value  is  nil. 


ac-key-symbols 

ac-key-labels 

ac-key-descriptions 

deflection-key-info 

ac-key-ranges 

ac-coefficient-symbols 


A  list  of  the  keys  used  to  access  the  results  of  the  Datcom  runs.  The 
contents  of  this  list  are  summarized  in  the  table  above  and  should 
not  be  changed  by  the  user. 

A  list  of  printed  names  corresponding  to  the  keys  in  ac-key-symbols. 
The  contents  of  this  list  are  summarized  in  the  table  above  and 
should  not  be  changed  by  the  user. 

A  list  of  descriptive  strings  corresponding  to  the  keys  in  ac-key- 
symbols.  The  contents  of  this  list  are  summarized  in  the  table 
above  and  should  not  be  changed  by  the  user. 

A  summary  of  key  information  reflecting  control  deflections.  The 
contents  of  this  list  should  not  be  changed  by  the  user. 

A  list  of  lists  of  the  values  which  will  be  used  for  each  key  in  Datcom. 
The  entries  in  this  list  come  from  properties  such  as  mach- 
numbers,  angles-of-attack,  etc.  and  should  not  be  changed  by  the 
user. 

A  list  of  the  symbols  representing  the  data  computed  by  Datcom  and 
stored  in  table-list.  The  contents  of  this  list  is  summarized  in  the 
table  above  and  should  not  be  changed  by  the  user. 


table-list  This  property  contains  the  cumulative  results  of  all  Datcom  runs 

required  to  produce  the  requested  data.  This  data  is  in  the  form  of 
a  list  of  lists.  Each  individual  list  contains  a  list  of  key  values  and  a 
list  of  coefficient  values.  The  order  of  the  key  and  coefficient 
values  corresponds  to  the  order  of  the  symbols  in  ac-key-symbols 
and  ac-coejficient-symbols . 
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methods 


generate-datcom-file 

run-datcom 


datcom-fitcon-class 


[Class] 


This  class  is  used  as  a  subobject  of  datcom-source-class.  When  used  as  a  subobject,  the 
mach  number  and  flight  angle  properties  will,  by  default,  get  the  value  of  the  property  in 
the  parent  datcom-source-class.  They  should  not  normally  be  overridden  by  the 
subobject. 


Note:  When  datcom-fitcon-class  is  used  as  a  subobject  of  datcom-source-class,  the 
following  properties  will  (by  default),  get  their  values  from  datcom-source-class:  mach- 
numbers,flight-conditions-angle-mode,  angles-of-attack,  sideslip-angles,  total-angles-of- 
attack,  and  roll-angles. 


This  class  provides  the  entries  for  the  FLTCON  namelist  in  the  Datcom  input  file. 


Datcom  Entry 

Corresponding  Property 

NALPHA 

automatic 

ALPHA 

angles-of-attack,  total- 

angles-of-attack 

BETA 

sideslip-angles 

PHI 

roll-angles 

Datcom  Entry 

Corresponding  Property 

MACH 

mach-numbers 

REN 

reynolds -numbers 

ALT 

altitude 

HYPER 

newtonian-flow? 
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NMACH  automatic 


SOSE  second-order-shock- 

expansion  ? 


Inherit-From: 


(object) 


Properties: 


mach-numbers 


flight-conditions-angle-r 


angles-of-attack 


sideslip-angles 


total-angle  s-of-attack 


roll-angles 


A  list  of  the  Mach  numbers  for  which  aerodynamic  coefficients  should 
be  computed  (e.g.,  '(0.7  0.8  0.9  1.2  1.5)).  The  formula  of  this 
property  should  normally  not  be  overridden.  The  default  formula 
is  (default  nil). 

lode  The  orientation  of  the  vehicle  can  be  specified  using  either  the 
body  axes  angles  or  total  angles.  If  the  value  is  'body-axes,  then 
the  properties  angles-of-attack  and  sideslip-angles  must  be  given 
values.  If  the  value  is  'total,  then  the  properties  total-angles-of- 
attack  and  roll-angles  must  be  given  values.  If  Xheflight- 
conditions-object  property  points  to  an  instance  oiflight- 
conditions-class,  then  the  value  of flight-conditions-angle-mode 
will  be  taken  from  that  object.  Allowable  values  for  flight- 
conditions-angle-mode  are  'body-axes  and  'total.  The  formula  of 
this  property  should  normally  not  be  overridden.  The  default 
formula  is  (default  Taody-axes). 

A  list  of  the  angles  of  attack  for  which  aerodynamic  coefficients  should 
be  computed  (e.g.,  '(0.0  5.0  10.0  15.0).  This  property  will  only  be 
used  vAiea  flight-conditions-angle-mode  is  'body-axes.  The 
formula  of  this  property  should  normally  not  be  overridden.  The 
default  formula  is  (default  nil) 

A  list  of  the  sideslip  angles  (in  degrees)  for  which  aerodynamic 
coefficients  should  be  computed  (e.g.,  '(0.0  2.0  4.0  8.0).  This 
property  will  only  be  used  when  flight-conditions-angle-mode  is 
'body-axes.  The  formula  of  this  property  should  normally  not  be 
overridden.  The  default  formula  is  (default  nil). 

A  list  of  the  total  angles  of  attack  (in  degrees)  for  which  aerodynamic 
coefficients  should  be  computed  (e.g.,  '(0.0  5.0  10.0  15.0).  This 
property  will  only  be  used  when  flight-conditions-angle-mode  is 
'total.  The  formula  of  this  property  should  normally  not  be 
overridden.  The  default  formula  is  (default  nil). 

A  list  of  the  roll  angles  (in  degrees)  for  which  aerodynamic  coefficients 
should  be  computed  (e.g.,  '(0.0  2.0  4.0  6.0).  This  property  will 
only  be  used  'f/h.en  flight-conditions-angle-mode  is  'total.  The 
formula  of  this  property  should  normally  not  be  overridden.  The 
default  formula  is  (default  nil). 

Flight  conditions  can  be  specified  for  a  range  of  altitudes  or  Reynold's 
numbers.  When  conditions -specifler  has  a  value  of  'ren,  the 
reynolds-numbers  property  should  contain  a  list  of  Reynold's 
numbers  for  which  aerodynamic  coefficients  will  be  computed. 


conditions-specifier 


When  conditions-specifier  has  a  value  of  dlt,  the  altitude  property 
should  contain  a  list  of  altitudes  for  which  aerodynamic 
coefficients  will  be  computed.  The  default  value  is  'alt. 
reynolds-numbers  When  conditions-specifier  has  a  value  of  'ren,  then  this  property  should 

contain  a  list  of  Reynold's  numbers  at  which  aerodynamic 
coefficients  should  be  computed.  The  number  of  Reynold's 
numbers  specified  should  correspond  to  the  number  of  mach- 
numbers.  The  default  is  a  list  with  all  elements  equal  to  1E6. 
altitude  When  conditions-specifier  has  a  value  of  'alt,  then  this  property  chould 

contain  a  list  of  altitudes  for  which  aerodynamic  coefficients  will 
be  computed.  The  number  of  altitudes  specified  should  correspond 
to  the  number  of  mach-numbers .  The  default  is  a  list  with  all 
elements  equal  to  0.0. 

second-order-shock-expansion?  When  the  value  of  this  property  is  t,  the  SOSE  card  will  be 

included  in  the  Datcom  input  file.  When  nil,  it  will  not. 
newtonian-flow?  When  the  value  of  this  property  is  t,  the  HYPER  card  will  be  included 

in  the  Datcom  input  file.  When  nil,  it  will  not. 


datcom-refq-class _ [Class] 

This  class  is  used  as  a  subobject  of  datcom-source-class. 


This  class  provides  the  entries  for  the  REFQ  namelist  in  the  Datcom  input  file. 


Datcom  Entry 

Corresponding  Property 

Datcom  Entry 

Corresponding  Property 

SREF 

reference-area 

XCG 

cg-position-longitudinal, 

trim-cg-position- 

longitudinal 

LREF 

reference-length- 

longitudinal 

ZCG 

cg-position-vertical 

LATREF 

reference-length-lateral 

SCALE 

scale-factor 

ROUGH 

surface-roughness 

BLAYER 

boundary-layer-type 

RHR 


roughness-rating 


Inherit-From: 


(object) 


Properties: 


fuselage-object 


reference-area 


This  property  should  point  to  an  instance  of  class  datcom-fuselage- 
interf ace-class.  Normally,  this  is  done  by  getting  its  value  from  the 
fuselage-interface-object  property  of  its  parent,  the  datcom- 
fuselage-interf ace-class.  The  formula  for  this  property  should  be 
^fuselage-interface-object. 

The  reference  area  of  the  vehicle.  When  fuselage-object  points  to  an 
instance  of  datcom-fuselage-interf ace-class,  this  value  will  be 


reference-length-longitudinal 

reference-length-lateral 

roughness-specifier 

surface-roughness 
roughness-rating 
cg-position-longitudinal 

trim-cg-position-longitudinal 

cg-position-vertical 


found  automatically  from  that  object.  The  formula  of  this  property 
should  normally  not  be  overridden. 

The  vehicle  longitudinal  reference  length.  Wh^n  fusel  age-object 
points  to  an  instance  of  datcom-fuselage-inteiface-class,  this  value 
will  be  found  automatically  from  that  object.  The  formula  of  this 
property  should  normally  not  be  overridden. 

The  vehicle  lateral  reference  length.  When  fuselage-object  points  to  an 
instance  of  datcorn-fuselage-mterf ace-class,  this  value  will  be 
found  automatically  from  that  object.  The  formula  of  this  property 
should  normally  not  be  overridden. 

Specifies  whether  the  surface-roughness  or  roughness-rating  propert}^ 
will  be  sent  to  Datcom.  When  roughness-specifier  is  'rough,  the 
surface-roughness  will  be  given.  When  roughness-specifier  is  'rhr, 
the  roughness-rating  will  be  given.  The  default  value  is  'rough. 

A  value  for  the  vehicle  surface  roughness.  This  will  only  be  written 
when  roughness-specifier  is  'rough.  The  default  value  is  0.0. 

A  value  for  the  vehicle  roughness  rating.  This  will  only  be  written 
when  roughness-specifier  is  'rhr.  The  default  value  is  0.0. 

The  longitudinal  position  of  the  vehicle  center  of  gravity.  This  value 
will  be  written  when  coefficients  are  computed  in  non-trim  cases. 
The  default  value  is  0.0. 

The  longitudinal  position  of  the  vehicle  center  of  gravity  under  trim 
conditions.  This  value  will  be  written  when  trim  coefficients  are 
computed.  The  default  value  is  52%  of  the  vehicle  length  when 
fuselage-object  is  specified  and  0.0  when  it  is  not. 

The  vertical  position  of  the  vehicle  center  of  gravity.  The  same  value 
will  be  used  for  trim  and  non-trim  conditions.  The  default  value  is 
0.0. 


scale-factor 

boundary-layer-type 


A  scale  factor  used  to  multiply  vehicle  dimensions  (other  than  reference 
dimensions).  The  default  value  is  1.0. 

A  specifier  for  the  type  of  boundary  conditions  to  be  used.  The 

available  options  are  'turb  and  'natural  The  default  value  is  'turb. 
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datcom-trim-class 


[Class] 


This  class  is  used  as  a  subobject  of  datcom-source-class. 


This  class  provides  the  entries  for  the  TRIM  namelist  in  the  Datcom  input  file. 


Datcom  Entry 

Corresponding  Property 

Datcom  Entry 

Corresponding  Property 

SET 

trim-fin-set-object 

DELMIN 

minimum-deflection 

PANE 

use-panel-flags-list 

DELMAX 

maximum-deflection 

ASYM 

flip-panel-deflection-list 

Inherit-From: 

(object) 


Properties: 

datcom-finset-propertieS’ObjectThis  property  should  point  to  an  instance  of  datcom-finset- 

properties-class .  Normally,  this  should  point  to  the  finsets 
subobject  of  the  datcom-source-class  object.  The  formula  for  this 
property  should  be  ^finsets. 

minimum-deflection  The  minimum  deflection  value  allowed  for  fms  during  trim 

con:q)utations.  The  default  value  is  -25.0. 

maximum-deflection  The  maximum  deflection  value  allowed  for  fins  during  trim 

computations.  The  default  value  is  25.0. 

use-panel-flags-list  A  list  of  values  (either  t  or  nil)  which  indicate  the  panels  of  a  finset 

which  that  can  be  deflected  during  trim  computations.  The  default 
value  will  be  a  list  with  all  t  elements  (all  panels  can  be  deflected). 

flip-panel-deflection-list  A  list  of  values  (either  t  or  nil)  which  indicate  whether  the  sign  of 

deflections  should  be  reversed.  The  default  value  will  be  a  list  of 
all  nil  elements  (all  panels  with  normal  deflection). 
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- - - 

datcom-finset-properties-class 

[Class] 

This  class  is  used  as  a  subobject  of  datcom-source-class. 

This  class  acts  as  an  intermediate  object  between  the  wing  descriptions  in  instances  of 

datcom-wing-set-interface-class  and  Datcom.  Normally,  nothing  should  be  changed  in 
this  class. 


This  class  provides  the  entries  for  the  FINSET  namelists  in  the  Datcom  input  file.  The 
actual  values  are  obtained  from  the  datcom-wing-set-interface-class  objects  referenced  by 
source-wing-sets. 


Inherit-From: 

(object) 


Properties: 

source-wing-sets  This  property  should  contain  a  list  of  references  to  instances  oidatcom- 

wing-set-interf ace-class.  Normally,  this  is  done  by  getting  its 
value  from  the  wing-set-geometry-objects  property  of  its  parent, 
the  datcom-source-class.  The  formula  of  this  property  should  be 
''^ing-set-geometry-objects. 

sorted-source-wing-sets  A  list  of  the  instances  specified  in  source-wing-sets  in  order  from 

vehicle  nose  to  tail.  This  should  not  be  changed  by  the  user. 


datcom-body-properties-class 


[Class] 


This  class  is  used  as  a  subobject  of  datcom-source-class. 


This  class  acts  as  an  intermediate  object  between  the  fuselage  description  in  an  instance 
ot  datcom-fuselage-interface-class  and  Datcom.  Normally,  nothing  should  be  changed  in 
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this  class. 


The  information  written  to  the  Datcom  input  file  will  either  be  geometry  based  or  from 
aerodynamic  coefficients  depending  on  the  settings  of  the  properties.  Control  of  this 
behavior  should  be  through  the  properties  of  the  datcom-fuselage-interface-class  instead 
of  this  object. 


This  class  provides  the  entries  for  the  ELLBOD  or  AXIBOD  namelist  in  the  Datcom 
input  file. 


Inherit-From: 

(object) 


Properties: 

fuselage-interface-object  This  property  should  point  to  an  instance  of  datcom-fuselage-interface- 

class.  Normally,  this  is  done  by  getting  its  value  form  ihefuselage- 
interface-object  property  of  its  parent,  the  datcom-source-class. 
The  formula  of  this  property  should  be  '^uselage-interface-object. 
fiiselage-aero-coeffs-source-object  This  property  should  point  to  an  instance  of  aerodynamic- 

coefficients-source-class  if  aerodynamic  coefficients  describing  the 
body  should  be  used  instead  of  a  geometric  description.  By 
default,  the  value  of  this  property  comes  fi'om  the  object  pointed  to 
by  fuselage-interface-object  and  it  should  not  be  changed  by  the 
user. 


datcom-protuberance-set-properties-class 


[Class] 


This  class  is  used  as  a  subobject  of  datcom-source-class . 


This  class  acts  as  an  intermediate  object  between  the  protuberance  set  descriptions  in  an 
instance  of  datcom-protuberances-interface-class  and  Datcom.  Normally,  nothing  should 
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be  changed  in  this  class. 


This  class  provides  the  entries  for  the  PROTUB  namelist  in  the  Datcom  input  file. 


Inherit-From: 

(object) 


Properties; 

protuberance-set-source-object  This  property  should  point  to  an  instance  of  datcom- 

protuberances-interf ace-class.  Normally,  this  is  done  by  getting 
its  value  from  the  protuberance-set-source-object  property  of  its 
parent,  the  datcom-source-class.  The  formula  of  this  property 
should  be  '^protuberance-set-source-object. 


datcom-inlet-properties-class 


[Class] 


This  class  is  used  as  a  subobject  oi datcom-source-class. 


This  class  acts  as  an  intermediate  object  between  the  inlet  description  in  an  instance  of 

datcom-inlet-interface-class  and  Datcom.  Normally,  nothing  should  be  changed  in  this 
class. 


This  class  provides  the  entries  for  the  INLET  namelist  in  the  Datcom  input  file. 


Inherit-From: 


(object) 


Properties: 

inlet-source-object  This  property  should  point  to  an  instance  of  datcom-inlet-interface- 

class.  Normally,  this  is  done  by  getting  its  value  from  the  inlet- 
source-object  property  of  its  parent,  the  datcom-source-class.  The 
formula  of  this  properly  should  be  ^inlet-source-object. 


datcom-fuselage-interface-class 


[Class] 


This  class  is  used  to  provide  an  interface  between  fuselage  information  and  Datcom.  All 
input  required  for  Datcom  can  be  specified  with  properties  of  this  object.  Additional 
methods  for  providing  information  are  also  provided. 


The  information  provided  to  Datcom  to  describe  the  vehicle  fuselage  can  be  either 
geometric  or  aerodynamic.  In  the  case  of  geometric  data,  properties  describing  the  shape 
of  the  nose,  center,  and  aft  sections  of  the  fuselage  must  be  provided.  For  the  case  of 
aerodynamic  data,  a  reference  to  an  instance  of  aerodynamic-coefficients-source-class 
must  be  provided.  If  coefficients  are  to  be  provided,  the  property  aero-coejfs-source- 
object  must  point  to  an  instance  of  aerodynamic-coefficients-source-class.  The  geometric 
properties  will  be  ignored.  If  aero-coeffs-source-object  is  nil,  then  the  geometric 
properties  will  be  used. 


When  the  fuselage  description  is  based  on  geometry,  the  actual  properties  describing  the 
nose,  center,  and  aft  section  geometry  are  contained  in  subobjects  of  datcom-fuselage- 
interface-class\  nose-info,  center-body-info,  and  aft-body-info.  The  datcom-input 
properties  of  datcom-fuselage-interface-class  get  their  values  from  the  corresponding 
properties  of  these  subobjects. 


Reference  Properties: 


The  reference  properties  reference-area,  reference-diameter-longitude,  reference- 
diameter-latitude,  and  body-length  may  have  their  values  computed  directly  from 
geometry;  found  from  a  body-geometry-interface-class  object;  foimd  based  on  the 
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properties  of  the  nose,  body,  and  aft  subobjects;  or  entered  directly  as  values.  If  the 
geometry-source-object  property  points  to  an  object  of  class  body-geometry-interface- 
class,  then  the  reference  properties  will  be  taken  from  that  object.  When  the  geometry- 
source-object  property  points  to  an  object  with  a  geom,  the  reference  properties  will  be 
determined  fi-om  that  geom  if  the  cs-info  property  is  not  nil  (see  Cross-Section  Query 
Properties  below).  To  determine  the  reference  properties  Ifom  the  nose,  body,  and  aft 
subobjects,  geometry-source-object  should  have  a  value  of  nil.  Directly  entering  values 
for  the  reference  properties  will  override  this  behavior. 


Cross-Section  Query  Properties: 


The  reference  properties  and  some  of  the  nose,  body,  and  aft  geometric  properties  can  be 
determined  directly  from  a  vehicle  fuselage  geom.  If  the  geometiy-source-object  property 
points  to  an  object  with  a  geom,  the  cs-info  property  will  contain  information  describing 
the  geometry  of  the  fuselage  at  locations  distributed  along  its  length.  The  properties 
which  control  the  determination  of  cross-section  information  are  cs-query-point,  cs- 
query-vector,  cs-query-coord-sys,  and  cs-query-cut-spacing.  The  cross-section-query 

property  is  an  instance  of  the  class  which  computes  the  query  results  and  should  not  be 
changed. 


This  object  provides  the  entries  for  the  fuselage  (AXIBOD  or  ELLBOD)  namelist  in  the 
Datcom  input  file.  The  actual  Datcom  input  is  written  from  and  instance  of  datcom-body- 
properties-class  which  references  an  instance  oi datcom-fuselage-interface-class. 


This  class  provides  entries  for  the  AXIBOD  or  ELLBOD  namlist  in  the  Datcom  input 
file.  ^ 


Datcom  Entry 

Corresponding 

Property 

Default  Source 

Subobject 

Source  Subobject 

Property 

LNOSE 

datcom-input-lnose 

nose-info 

nose-length 

DNOSE 

datcom-input-dnose 
- - - 

nose-info 

nose-diameter 
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WNOSE 

datcom-input-dnose 

nose-info 

nose-diameter 

TNOSE 

datcom-input-tnose 

nose-info 

nose-type 

BNOSE 

datcom-input-bnose 

nose-info 

nose-bluntness 

TRUNC 

datcom-input-trunc 

nose-info 

nose-truncated? 

ENOSE 

datcom-input-enose 

nose-info 

nose-ellipticity 

POWER  datcom-input-power  nose-info 


datcom-input-nose-  nose-info 
shape 


LCENTR  datcom-input-lcentr  center-body-info 


DCENTR  datcom-input-dcentr  center-body-info 

WCENTR  datcom-input-dcentr  center-body-info 

ECENTR  datcom-input-ecentr  center-body-info 


datcom-input-center-  center-body-info 
shape 

LAFT  datcom-input-laft  aft-body-info 


DAFT  datcom-input-daft  aft-body-info 


WAFT  datcom-input-daft  aft-body-info 

DEXrr  datcom-input-dexit  aft-body-info 

TAFT  datcom-input-taft  aft-body-info 


EAFT  datcom-input-eaft  aft-body-info 


datcom-input-aft- 

shape 


aft-body-info 


aft-body-info 

aft-body-info 


datcom-input-base-  aft-body-info 


nose-power 


nose-cs-shape 


center-length 


center-diameter 

center-diameter 

center-ellipticity 


center-cs-shape 

aft-length 


aft-diameter 


aft-diameter 

exit-diameter 

aft-type 


aft-ellipticity 

aft-cs-shape 

ignor e-base-drag? 
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- — - 1 - — — - 

drag? 

Inherit-From: 

(datcom-input-source-object-mixin) 


Properties: 

aero-coeffs-source-object  If  this  property  points  to  an  instance  of  aerodynamic-coefficients- 

source-class,  then  the  aerodynamic  coefficients  provided  by  that 
object  will  be  sent  to  Datcom  instead  of  iiiforrnation  describing  the 
fuselage  geometry.  If  the  value  of  this  property  is  nil,  then  the 
geometric  properties  will  be  written. 

geometiy-source-object  This  property  should  point  to  an  object  which  has  a  geom  representing 

the  overall  fuselage  geometry  or  to  an  instance  of  body-geometiy- 
interface-class  which  describes  the  fuselage.  When  it  does,  that 
geometry  can  be  used  to  determine  reference  and  cross-section 
properties. 


cs-query-point 

cs-query-vector 

cs-query-coord-sys 

cs-query-cut-spacing 

cross-section-query 

cs-info 


The  cross-section  cuts  will  be  made  along  the  fuselage  in  the  cs-query- 
vector  direction  starting  at  this  point.  The  default  value  is  YO  0  0  0 
0.0). 

This  property  contains  the  direction  along  which  cross-section  cuts  will 
be  made.  The  default  value  is  YTO  0.0  0.0). 

This  property  should  point  to  an  instance  of  coordinate-systeni-clciss  in 
which  the  cs-queiy-point  and  cs-query-vector  are  defined.  The 
default  value  of  nil  indicates  the  global  coordinate  system. 

This  value  of  this  property  is  the  spacing  between  cross-section  cuts 
that  are  made  in  the  fuselage.  The  default  value  is  1.0. 

This  property  is  actually  an  instance  of  the  class  cross-section- 

par  ameters-along-axis -class,  This  object  is  used  to  determine  the 
cross-section  properties  of  the  fuselage  distributed  along  the  length 
of  the  fuselage.  This  object  should  not  be  changed  by  the  user. 

This  property  contains  the  results  of  the  cross-section  query  operation. 
The  formula  and  value  of  this  property  should  normally  not  be 
changed  by  the  user. 


ref-info 


reference-area 


reference-diameter-longitude 


This  property  contains  the  results  of  internal  queries  for  the  reference 
geometric  properties  of  the  fuselage  (as  described  above).  If  the 
queries  are  not  successful,  the  value  of  this  property  will  be  nil  If 
successful,  it  will  contain  a  list  of  values:  {reference-area 
reference-diameter-latitude  reference-diameter-longitude  body- 
length). 

The  reference  cross-sectional  area  of  the  vehicle  fuselage.  By  default, 
this  will  be  the  first  value  in  the  list  contained  in  ref-info.  If  ref-  ' 
info  is  nil,  the  default  value  of  1.0  will  be  used. 

The  longitudinal  reference  diameter  of  the  vehicle  fuselage.  By 
default,  this  will  be  the  third  value  in  the  list  contained  in  ref -info. 
If  ref-info  is  nil,  the  default  value  of  1 .0  will  be  used. 


54 


reference-diameter-latitude  The  lateral  reference  diameter  of  the  vehicle  fuselage.  By  default, 

this  will  be  the  second  value  in  the  list  contained  m  ref-info.  If  ref- 
info  is  nil,  the  default  value  of  1.0  will  be  used. 

body-length  The  reference  length  of  the  vehicle  fuselage.  By  default,  this  will  be  the 

fourth  value  in  the  list  contained  in  ref-info. 


The  default  values  of  the  following  properties  come  from  the  values  of  properties  in  the 
subobjects  of  the  datcom fuselage-interface-class.  The  locations  and  names  of  these 
properties  are  given  in  the  table  above.  A  description  of  the  properties  can  be  found  in 
the  class  definitions  of  their  respective  subobjects.  The  values  of  the  subobject  properties 
can  be  overridden  by  giving  the  datcom-fuselage-interface-class  properties  values 
directly. 


datcom-input-lnose 

datcom-input-dnose 

datcom-input-lcentr 

datcom-input-dcentr 

datcom-input-laft 

datcom-input-daft 

datcom-input-dexit 

datcom-input-base-drag? 

datcom-input-tnose 

datcom-input-bnose 

datcom-input-trunc 

datcom-input-enose 

datcom-input-nose-shape 

datcom-input-taft 

datcom-input-eaft 

datcom-input-aft-shape 

datcom-input-ecentr 

datcom-input-center-shape 

datcom-input-power 


datcom-wing-set-interface-class 


[Class] 


This  object  provides  an  interface  between  wing  geometry  and  Datcom.  If  the  source- 
object  property  points  to  an  instance  of  wing-set-class,  then  the  values  of  the  other 
properties  will  be  taken  directly  from  that  object  (with  the  exception  of  deflection- 
angles).  If  source-object  is  nil,  then  all  values  must  be  set  by  the  user. 


This  object  provides  the  entries  for  the  FINSET  namelist  in  the  Datcom  input  file.  If  the 
airfoil  section  type  is  NACA,  it  also  provides  information  for  the  corresponding  NACA 
entry  in  the  input  file. 
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Datcom  Entry 

Corresponding  Property 

Datcom  Entry 

Corresponding  Property 

SECTYP 

section-type 

ZUPPER 

wing-set-profde-in fo 

SSPAN 

semi-spans 

ZLOWER 

wing-set-profile-info 

CHORD 

chords 

LMAXU 

wing-set-profile-info 

XLE 

xle 

LMAXL 

wing-set-profile-info 

SWEEP 

sweep-angles 

LFLATU 

wing-set-profile-in fo 

STA 

sweep-stations 

LFALTL 

wing-set-profile-in fo 

NPANEL 

npanel 

LER 

wing-set-profile-info 

PHIF 

wing-phis 

CFOC 

flap-chord-ratios 

GAMMA 

wing-gammas 

Inherit-From: 

(datcom-input-source-object-mixin) 


Properties: 

source-object 


section-type 

semi-spans 

chords 

xle 

sweep-angles 


If  this  property  points  to  an  instance  of  wing-set-class,  the  values  of  the 
other  properties  in  this  object  will  be  taken  directly  from  that 
object  (with  the  exception  of  deflection-angles).  By  default,  this 
property  has  a  value  of  nil  and  all  values  must  be  entered  manually. 

The  section  type  of  the  airfoil  used  for  the  wing.  Allowed  values  are 
'hex,  'naca,  'arc,  and  'user.  The  default  value  is  nil.  The  object 
does  not  support  passing  toer-related  information  to  Datcom. 

A  list  of  the  span  positions  of  each  airfoil  section.  The  default  value  in 
manual  mode  is  '(0.0  1 .0). 

A  list  of  the  chords  of  each  airfoil  section.  The  default  value  in  manual 
mode  is  '(1.0  1.0). 

The  position  along  the  fuselage  of  the  front  of  the  root  airfoil.  The 
default  value  in  manual  mode  is  0.0. 

The  sweep  angles  between  airfoils.  The  default  value  in  manual  mode 
is  '(0.0). 
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sweep-stations  The  relative  position  in  each  airfoil  where  sweep  is  measured.  The 

default  value  in  manual  mode  is  '(0.0). 

npanel  The  number  of  wings  in  this  wing  set.  The  default  value  in  manual 

mode  is  equal  to  the  number  of  angles  specified  in  wing-phis. 

wing-phis  The  angular  positions  (about  the  fuselage)  of  the  wings  in  this  wing  set. 

The  default  value  in  manual  mode  is  ’(0.0). 

wing-gammas  The  root  dihedral  angles  of  the  wings  in  this  wing  set.  The  default 

value  in  manual  mode  is  '(0.0). 

deflection-angles  The  control-surface  deflection  angles  of  each  wing  in  the  wing  set.  The 

default  value  is  nil.  Even  when  source-object  points  to  a  wing-set- 
class,  this  value  must  be  entered  manually. 

xhinge  The  distance  of  the  control  surface  hinge  from  the  vehicle  nose.  The 

default  value  in  manual  mode  is  0.0. 

hinge-skew-angle 

flap-chord-ratios  The  location  along  the  airfoil  chord  of  the  flap  leading  edge.  The 

default  value  in  manual  mode  is  '(0.0  0.0). 

wing-set-profile-info  A  list  of  information  which  describes  the  airfoil  profiles.  The  contents 

of  this  list  will  depend  on  the  airfoil  type  {section-type).  For  the 
'hex  and  'arc  airfoil  sections,  different  values  may  be  entered  for 
each  airfoil  along  the  span. 

'hex\  (list 'hex 

(list  of  thickness-to-chord-ratio-upper) 

(list  of  thickness-to-chord-ratio-lower) 

(list  of  leading-edge-ratio-upper) 

(list  of  leading-edge-ratio-lower) 

(list  of flat-ratio-upper) 

(list  of flat-ratio-lower) 

(list  of  leading-edge-radius) 

) 

'arc:  (list  'arc 

(list  of  thickness-to-chord-ratio-upper) 

(list  of  thickness-to-chord-ratio-lower) 

(list  of  leading-edge-radius) 

) 

'naca:  (list  'naca 

naca-series-type 

naca-series-number 

) 


datcom-protuberances-interface-class _ [Class] 

This  object  provides  an  interface  between  protuberance  geometry  and  Datcom. 


This  object  provides  the  entries  for  the  PROTUB  namelist  in  the  Datcom  input  file. 


Datcom  Entry  Corresponding  Property 


Datcom  Entry  Corresponding  Property 


NPROT 

LPROT 

PTYPE 

WPROT 

XPROT 

HPROT 

XLOC 

OPROT 

Inherit-From: 


(datcom-input-source-object-mixin) 


Properties: 

source-objects  This  property  should  point  to  an  instance  of  protuberance-series-class. 

The  values  written  to  the  Datcom  input  file  will  be  taken  from  this 
object. 

num-protuberance-sets  The  number  of  protuberance  sets  referred  to  in  source-objects.  This 

should  not  be  changed  by  the  user. 

num-protuberances  The  total  number  of  protuberances  in  all  protuberance  sets.  This  should 

not  be  changed  by  the  user. 

datcom-inlet-interface-class  - — 7 


This  object  provides  an  interface  between  inlet  geometry  and  Datcom.  If  the  inlet- 
geometry-object  property  points  to  an  instance  of  inlet-set-class,  then  the  values  of  the 
other  properties  will  be  taken  directly  from  that  object.  If  inlet-geometry-object  is  nil 
then  all  values  must  be  set  by  the  user. 


This  object  provides  the  entries  for  the  INLET  namelist  in  the  Datcom  input  file. 


Datcom  Entry 

Corresponding  Property 

Datcom  Entry 

Corresponding  Property 

NIN 

da  tcom  -input-nin 

X 

datcom-input-x 

INTYPE 

da  tcom  -input-intype 

H 

datcom-input-h 
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XINLT 

datcom-input-xinlt 

W 

datcom-input-w 

XDIV 

datcom-input-xdiv 

COVER 

datcom-input-cover 

HDIV 

datcom-input-hdiv 

RAMP 

datcom-input-ramp 

LDIV 

datcom-input-ldiv 

ADD 

datcom-input-add 

PHI 

datcom-input-phi 

MFR 

datcom-input-mfr 

Inherit-From: 

(datcom-input-source-object-mixin) 


Properties: 

inlet-geometry-object  If  this  property  points  to  an  instance  of  inlet-set-class,  the  values  of  the 

other  properties  in  this  object  will  be  taken  directly  from  that 
object.  By  default,  this  property  has  a  value  of  nil  and  all  values 
must  be  set  manually. 

inlet-interface-data  If  inlet-geometry-object  points  to  an  instance  of  inlet-set-class,  then  the 

inlet  geometry  properties  in  the  class  will  be  set  automatically. 


The  default  values  of  the  following  properties  are  obtained  directly  from  the  object 
pointed  to  by  inlet-geometry-object.  The  values  may  be  set  or  overridden  by  giving  the 
datcom-inlet-interface-class  properties  values  directly. 


datcom-input-nin 

datcom-input-intype 

datcom-input-xinlt 

datcom-input-xdiv 

datcom-input-hdiv 

datcom-input-ldiv 

datcom-input-phi 

datcom-input-x 

datcom-input-h 

datcom-input-w 

datcom-input-cover 


datcom-input-ramp 

datcom^input-add 

datcom-input-mfr 


datcom-nose-interface-class 


This  class  is  normally  used  as  a  subobject  of  datcom-fuselage-interface-class.  It  acts  as 
an  interface  between  the  vehicle  nose  geometry  and  the  Datcom  fuselage  information.  If 
all  Datcom  properties  are  being  set  manually,  they  can  be  changed  in  the  datcom- 
fuselage-interface-class  and  this  class  may  be  ignored. 


This  class  can  operate  in  three  different  modes  based  on  the  value  of  the  source-mode 
property,  local,  fuselage,  and  manual.  The  following  table  surrunarizes  the  input  required 
for  different  values  of  source-mode.  If  the  "user  provides"  and  "can  compute" 
requirements  are  not  met,  then  all  input  will  be  manual. 


source-mode 

is 

'manual 

'local 

'fuselage 

user  provides 

nothing 

geometry-source-object 

nothing 

fuselage-cs- 

info 

can  compute 

nose-source- 

info 

cs-info 

nose-length 

manual 

automatic 

computed 

manual 

computed 

nose- 

diameter 

manual 

automatic 

computed 

manual 

computed 

nose-type 

manual 

automatic 

manual 

manual 

manual 

nose- 

bluntness 

manual 

automatic 

manual 

manual 

manual 

nose- 

truncated? 

manual 

automatic 

manual 

manual 

manual 

60 


nose- 

ellipticity 

manual 

automatic 

manual 

manual 

manual 

nose-cs- 

shape 

manual 

automatic 

manual 

manual 

manual 

nose-power 

manual 

automatic 

manual 

manual 

manual 

This  class  provides  entries  for  the  AXBBOD  or  ELLBOD  namelist  in  the  Datcom  input 
file. 


Datcom  Entry 

Corresponding  Property 

TRUNC 

nose-truncated? 

ENOSE 

nose-ellipticity 

POWER 

nose-power 

Datcom  Entry 

Corresponding  Property 

LNOSE 

nose-length 

DNOSE 

nose-diameter 

TNOSE 

nose-type 

BNOSE 

nose-bluntness 

Inherit-From: 

(datcom-input-source-obj  ect-mixin) 


Properties: 

fuselage-geometry-source-object  This  property  should  contain  a  ^/ze-reference  to  an  instance  of 

an  object  with  a  geom  which  represents  the  vehicle  fuselage.  This 
is  available  for  reference  but  is  not  used  by  this  object.  Normally, 
the  value  of  this  property  is  available  from  the  object’s  parent  and 
its  default  formula  ^geometry-source-object  should  not  be 
changed. 

fuselage-cs-info  This  property  contains  information  that  describes  cross-section 

information  for  the  fuselage.  Normally,  the  value  of  this  property 
is  available  from  the  object's  parent  and  its  default  formula  ^cs- 
info  should  not  be  changed. 
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source-mode 


geometry-source-obj  ect 


This  property  is  used  to  specify  where  the  values  of  the  properties 
describing  the  nose  geometry  should  come  from.  Allowed  values 
are  'fuselage,  'local,  and  'manual. 

The  object  instance  pointed  to  by  this  property  is  used  differently 
depending  on  the  value  of  source-mode. 


nose-source-info 


nose-info 

nose-lengtii 

nose-diameter 

nose-type 

nose-bluntness 

nose-truncated? 

nose-ellipticity 

nose-cs-shape 

nose-power 

cs-query-point 

cs-query-vector 

cs-query-coord-sys 


cs-query-cut-spacing 


cross-section-query 


If  the  source-mode  is  'local  and  the  geometiy -source-object  points  to  a 
Datcom  fuselage  or  nose  geometry  object,  then  this  property  will 
contain  geometric  information  from  that  object.  If  these  conditions 
are  not  met,  then  this  property  will  have  a  value  of «//.  The 
formula  of  this  property  should  not  be  changed  by  the  user. 

This  property  will  contain  geometric  information  about  the  nose  which 
depends  on  the  values  of  other  properties  in  this  object.  The 
formula  of  this  property  should  not  be  changed  by  the  user. 

The  length  of  the  vehicle  nose.  The  default  value  depends  on  source¬ 
mode  (see  above).  In  manual  mode  the  default  value  is  1 .0 

The  diameter  of  the  vehicle  nose.  The  default  value  depends  on  source¬ 
mode  (see  above).  In  manual  mode  the  default  value  is  1.128. 

The  type  of  vehicle  nose.  The  allowed  values  are  'cone,  'ogive,  'power, 
kai  man,  and  hack.  In  manual  mode,  the  default  value  is  'cone. 

The  bluntness  of  the  vehicle  nose.  The  default  value  depends  on 
source-mode  (see  above).  In  manual  mode,  the  default  value  is 

Indicates  whether  the  nose  is  tmncated  or  not.  Allowed  values  are  t  and 
nil.  The  default  value  depends  on  source-mode  (see  above).  In 
manual  mode  the  default  value  is  nil. 

Indicates  the  ellipticity  of  the  nose  when  nose-cs-shape  is  'elliptical. 

The  default  value  depends  on  source-mode  (see  above).  In  manual 
mode  the  default  value  is  1.0. 

Indicates  whether  the  cross-sections  of  the  nose  are  circular  or 

elliptical.  Allowed  values  are  'circular  and  'elliptical.  The  default 
value  depends  on  source-mode  (see  above).  In  manual  mode  the 
default  value  is  'circular. 

The  power  of  the  nose  shape  when  nose-type  is  'power.  The  default 
value  depends  on  source-mode  (see  above).  In  manual  mode  the 
default  value  is  1.0, 

The  cross-section  cuts  will  be  made  along  the  nose  geometry  in  the  cs- 
queiy-vector  direction  starting  at  this  point.  The  default  value  is 
’(0.0  0.0  0.0).  This  property  is  only  required  when  the  source¬ 
mode  is  'local  and  nose-source-info  is  nil. 

This  property  contains  the  direction  along  which  cross-section  cuts  will 
be  mad.  The  default  value  is  '(1.0  0.0  0.0).  This  property  is  only 

required  when  the  source-mode  is  'local  and  nose-source-info  is 
nil. 

This  property  should  point  to  an  instance  of  coordinate-system-class  in 
which  the  cs-query-point  and  cs-query-vector  are  defined.  The 
default  value  of  nil  indicates  the  global  coordinate  system.  This 
property  is  only  required  when  the  source-mode  is  'local  and  nose- 
source-info  is  nil. 

The  value  of  this  property  is  the  spacing  between  the  cross-section  cuts 
that  are  made  in  the  nose  geometry.  The  default  value  is  1 .0.  This 
property  is  only  required  when  the  source-mode  is  'local  and  nose- 
source-info  is  nil. 

This  property  is  actually  an  instance  of  the  class  cross-section- 

parameters-along-axis-class.  This  object  is  used  to  determine  the 
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cross-section  properties  of  the  nose  geometry  distributed  along  its 
length.  This  object  should  not  be  changed  by  the  user, 
cs-info  This  property  contains  the  results  of  the  cross-section  query  operation 

and  is  normally  only  demanded  when  the  source-mode  is  'local  and 
nose-source-info  is  nil.  The  formula  and  value  of  this  property 
should  normally  not  be  changed  by  the  user. 


datcom-center-body-interface-class 


[Class] 


This  class  is  normally  used  as  a  subobject  of  datcom-fuselage-interface-class.  It  acts  as 
an  interface  between  the  vehicle  center-body  geometry  and  the  Datcom  fuselage 
information.  If  all  Datcom  properties  are  being  set  manually,  they  can  be  changed  in  the 
datcom-fuselage-interface-class  and  this  class  my  be  ignored. 


This  class  can  operate  in  three  different  modes  based  on  the  value  of  the  source-mode 
property:  local,  fuselage,  and  manual.  The  following  table  summarizes  the  input  required 
for  different  values  of  source-mode.  If  the  "user  provides"  and  "can  compute" 
requirements  are  not  met,  then  all  input  will  be  manual. 


source-mode 

is 

^manual 

'local 

'fuselage 

user  provides 

nothing 

geometry-source-object 

nothing 

fuselage-cs- 

info 

can  compute 

center-body- 

source-info 

cs-info 

center-length 

manual 

automatic 

computed 

manual 

computed 

center- 

diameter 

manual 

automatic 

computed 

manual 

computed 

center- 

ellipticity 

manual 

automatic 

manual 

manual 

manual 

center-cs- 

shape 

manual 

automatic 

manual 

manual 

manual 
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Note:  Currently,  a  source-mode  of  'fuselage  is  not  supported  and  it  will  work  like 
manual. 


This  class  provides  entries  for  the  AXIBOD  or  ELLBOD  namelist  in  the  Datcom  input 
file.  ^ 


Datcom  Entry 

Corresponding  Property 

Datcom  Entry 

Corresponding  Property 

LCENTR 

center-length 

ECENTR 

center-ellipticity 

DCENTR 

center-diameter 

Inherit-From; 

(datcom-input-source-object-mixin) 


Properties: 


se  age-geometry-source-object  This  property  should  contain  a  t/ie-reference  to  an  instance  of 

an  object  with  a  geom  which  represents  the  vehicle  fuselage.  This 
is  available  for  reference  but  is  not  used  by  this  object.  Normally, 
the  value  of  this  property  is  available  from  the  object's  parent  and 
its  default  formula  '^geometiy-source-object  should  not  be 
changed. 

This  property  contains  information  that  describes  cross-section 

information  for  the  fuselage.  Normally,  the  value  of  this  property 
is  available  from  the  object's  parent  and  its  default  formula  ^cs- 
info  should  not  be  changed. 

Tills  property  is  used  to  specify  where  the  values  of  the  properties 
describing  the  nose  geometry  should  come  from.  Allowed  values 
are  fuselage,  local,  and  'manual.  Currently,  'fuselage  is  not 
supported  and  will  behave  like  'manual. 
geometry-source-object  The  object  instance  pointed  to  by  this  property  is  used  differently 

depending  on  the  value  of  source-mode. 


fiiselage-cs-info 


source-mode 


center-length 

center-diameter 


The  length  of  the  vehicle  center  body.  The  default  value  depends  on 
source-mode  (see  above).  In  manual  mode  the  default  value  is  1 .0. 
The  diameter  of  the  vehicle  center  body.  The  default  value  depends  on 
SOU}  ce-mode  (see  above).  In  manual  mode  the  default  value  is 
1.128. 
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center-ellipticity  Indicates  the  ellipticity  of  the  center  body  when  center-cs-shape  is 

'elliptical.  The  default  value  depends  on  source-mode  (see  above). 
In  manual  mode  the  default  value  is  1.0 

center-cs-shape  Indicates  whether  the  cross-sections  of  the  nose  are  circular  or 

elliptical.  Allowed  values  are  'circular  and  'elliptical.  The  default 
value  depends  on  source-mode  (see  above).  In  manual  mode  the 
default  value  is  'circular. 


cs-query-point  The  cross-section  cuts  will  be  made  along  the  center  body  geometry  in 

the  cs-query-vector  direction  starting  at  this  point.  The  default 
value  is  '(0.0  0.0  0.0).  This  property  is  only  required  when  the 
source-mode  is  'local  and  nose-source-info  is  nil 
cs-query-vector  This  property  contains  the  direction  along  which  cross-section  cuts  will 

be  mad.  The  default  value  is  ’(1.0  0.0  0.0).  This  property  is  only 
required  when  the  source-mode  is  'local  and  nose-source-info  is 
nil. 

cs-query-coord-sys  This  property  should  point  to  an  instance  of  coordinate-system-class  in 

which  the  cs-query-point  and  cs-query-vector  are  defined.  The 
defautl  value  of  nil  indicates  the  global  coordinate  system.  This 
property  is  only  required  when  the  source-mode  is  'local  and  nose- 
source-info  is  nil. 

cs-query-cut-spacing  The  value  of  this  property  is  the  spacing  between  the  cross-section  cuts 

that  are  made  in  the  center  body  geometry.  The  default  value  is 
1.0.  This  property  is  only  required  when  the  source-mode  is  'local 
and  nose-source-info  is  nil. 

cross-section-query  This  property  is  actually  an  instance  of  the  class  cross-section- 

parameters-along-axis-class.  This  object  is  used  to  determine  the 
cross-section  properties  of  the  center  body  geometry  distributed 
along  its  leng^.  This  object  should  not  be  changed  by  the  user, 
cs-info  This  property  contains  the  results  of  the  cross-section  query  operation 

and  is  normally  only  demanded  when  the  source-mode  is  'local  and 
center-body-source-info  is  nil.  The  formula  and  value  of  this 
property  should  normally  not  be  changed  by  the  user. 


datcom-aft-body-interface-class 


[Class] 


This  class  is  normally  used  as  a  subobject  of  datcom-fuselage-interf ace-class.  It  acts  as 
an  interface  between  the  vehicle  aft  body  geometry  and  the  Datcom  fuselage  information. 
If  all  Datcom  properties  are  being  set  manually,  they  can  be  changed  in  the  datcom- 
fuselage-interface-class  and  this  class  may  be  ignored. 


This  class  can  operate  in  three  different  modes  based  on  the  value  of  the  source-mode 
property:  local,  fuselage,  and  manual.  The  following  table  summarizes  the  input  required 
for  different  values  of  source-mode.  If  the  "user  provides"  and  "can  compute" 
requirements  are  not  met,  then  all  input  will  be  manual. 
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source-mode 

is 

'manual 

'local 

'fuselage 

user  provides 

nothing 

geometry-source-object 

nothing 

fuselage-cs- 

info 

can  compute 

aft-body- 

source-info 

cs-info 

aft-length 

manual 

automatic 

computed 

manual 

computed 

aft-diameter 

manual 

automatic 

computed 

manual 

computed 

forward- 

diameter 

manual 

automatic 

computed 

manual 

computed 

exit-diameter 

manual 

automatic 

ignore-base- 

drag? 

manual 

manual 

manual 

manual 

manual 

aft-type 

manual 

automatic 

manual 

manual 

manual 

aft-ellipticity 

manual 

automatic 

manual 

manual 

manual 

aft-cs-shape 

manual 

automatic 

manual 

manual 

manual 

Note:  Currently,  a  source-mode  of  'fuselage  is  not  supported  and  it  will  work  like 
manual. 


This  class  provides  entries  for  the  AXffiOD  or  ELLBOD  namelist  in  the  Datcom  input 


Datcom  Entry 

Corresponding  Property 

Datcom  Entry 

Corresponding  Property 

LAFT 

aft-length 

TAFT 

aft-type 

66 


DAFT 

aft-diameter 

EAFT 

aft-ellipticity 

DEXIT 

exit-diameter 

Inherit-From: 

(datcom-input-source-obj  ect-mixin) 


Properties: 

fuselage-geometry-source-object  This  property  should  contain  a  ?/ee-reference  to  an  instance  of 

an  object  with  a  geom  which  represents  the  vehicle  fuselage.  This 
is  available  for  reference  but  is  not  used  by  this  object.  Normally, 
the  value  of  this  property  is  available  from  the  object’s  parent  and 
its  default  formula  ^geometry-source-object  should  not  be 
changed. 

fuselage-cs-info  This  property  contains  information  that  describes  cross-section 

information  for  the  fuselage.  Normally,  the  value  of  this  property 
is  available  from  the  object’s  parent  and  its  default  formula  ^cs- 
info  should  not  be  changed. 


source-mode 

This  property  is  used  to  specify  where  the  values  of  the  properties 
describing  the  aft  body  geometry  should  come  from.  Allowed 
values  are  fuselage,  'local,  and  'manual  Currently,  'fuselage  is  not 
supported  and  will  behave  like  'manual 

geometry-source-obj  ect 

The  object  instance  pointed  to  by  this  property  is  used  differently 
depending  on  the  value  of  source-mode. 

aft-length 

The  length  of  the  vehicle  aft  body.  The  default  value  depends  on 

source-mode  (see  above).  In  manual  mode  the  default  value  is  1.0. 

aft-diameter 

The  diameter  of  the  aft  end  of  the  vehicle  aft  body.  The  default  value 
depends  on  source-mode  (see  above).  In  manual  mode  the  default 
value  is  1.128. 

forward-diameter 

exit-diameter 

ignore-base-drag? 

The  diameter  of  the  front  of  the  vehicle  aft  body.  The  default  value 
depends  on  source-mode  (see  above). 

aft-type 

The  type  of  vehicle  aft  body.  The  allowed  values  are  'cone,  'conical, 
and  'ogive.  In  manual  mode  the  default  value  is  'conical 

aft-ellipticity 

Indicates  the  ellipticity  of  the  nose  when  aft-cs-shape  is  'elliptical  The 
default  value  depens  on  source-mode  (see  above).  In  manual  mode 
the  default  value  is  1,0. 

aft-cs-shape 

Indicates  whether  the  cross-sections  of  the  aft  body  are  circular  or 

elliptical.  Allowed  values  are  'circular  and  'elliptical  The  default 
value  depens  on  source-mode  (see  above).  In  manual  mode  the 
default  value  is  'circular. 
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cs-query-point 


cs-query-vector 


cs-query-coord-sys 


cs-query-cut-spacing 


cross-section-query 


cs-info 


The  cross-section  cuts  will  be  made  along  the  aft  body  geometry  in  the 
cs-queiy-vector  direction  starting  at  this  point.  The  default  value  is 
'(0.0  0.0  0.0).  This  property  is  only  required  when  the  source¬ 
mode  is  local  and  nose-source-info  is  nil. 

This  property  contains  the  direction  along  which  cross-section  cuts  will 
be  mad.  The  default  value  is  ’(1.0  0.0  0.0).  This  property  is  only 
required  when  the  source-mode  is  local  and  nose-source-info  is 
nil 


This  property  should  point  to  an  instance  of  coordinate-system-class  in 
which  the  cs-queiy-point  and  cs-query-vector  are  defmed.  The 
defautl  value  of  nil  indicates  the  global  coordinate  system.  This 
property  is  only  required  when  the  source-mode  is  local  and  nose- 
source-info  is  nil. 

The  value  of  this  property  is  the  spacing  between  the  cross-section  cuts 
that  are  made  in  the  aft  body  geometry.  The  default  value  is  1.0. 
This  property  is  only  required  when  the  source-mode  is  local  and 
nose-source-info  is  nil. 

This  property  is  actually  an  instance  of  the  class  cross-section- 

parameters-along-axis-class.  This  object  is  used  to  determine  the 
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cross-section  properties  of  the  aft  body  geometry  distributed  along 
its  length.  This  object  should  not  be  changed  by  the  user, 
property  contains  the  results  of  the  cross-section  query  operation 
and  is  normally  only  demanded  when  the  source-mode  is  local  and 
aft-body -source-info  is  nil.  The  formula  and  value  of  this  property 
should  normally  not  be  changed  by  the  user. 


Tbs  class  exists  to  provide  a  common  class  for  the  interface  classes  to  inherit  from.  It 
adds  no  special  properties  or  behavior. 


Inherit-From; 

(object) 


Properties: 


Appendix  4:  AML  Panair  Interface  Documentation 


This  documentation  assumes  that  the  user  is  familiar  with  the  parameters  required  for  the 
PANAIR  input  file. 


The  basic-panair-class  provides  the  primary  interface  to  the  PANAIR  application. 
Control  of  PANAIR  is  though  properties  in  this  object  and  in  its  children.  Additional 
subobjects  will  need  to  be  added  (particularly  to  the  networks  subobject)  to  interface  to 
the  vehicle  geometry. 


All  of  the  capabilities  of  this  interface  to  PANAIR  can  be  accessed  through  properties. 
Users  will  normally  not  need  to  call  any  methods. 


The  basic-panair-class  object  will  compute  results  for  multiple  values  of  angle  of  attack, 
sideslip  angle,  and  Mach  numbers  by  performing  multiple  runs  of  PANAIR.  Typically, 
the  ability  to  run  multiple  solutions  of  during  one  run  of  PANAIR,  although  available,  is 
not  used.  This  functionality  is  discussed  under  the  panair-onset-flow-conditions- 
properties-class  documentation. 


Two  classes  are  provided.  The  basic-panair-class  provides  the  basic  interface  to 
PANAIR.  The  panair-class  inherits  from  this  class  and  adds  the  common  aerodynamic 
coefficient  access  interface  provided  hy  aerodynamic-coefficients-source-class. 


basic-panair-class 


[Class] 


This  class  provides  the  primary  interface  to  the  PANAIR  application. 


The  basic-panair-class  has  several  subobjects,  most  of  which  have  properties  that  should 
be  changed  by  the  user.  In  order  to  change  the  values  or  formulas  of  these  properties, 
new  classes  will  need  to  be  created  (inheriting  from  the  originals)  with  replacement 
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formulas  and  put  in  the  subobjects  section  of  a  new  class  inheriting  from  basic-panair- 
class.  The  subobjects,  their  classes,  and  whether  they  contain  user-editable  properties  are 
summarized  in  this  table: 


Subobject  Name 

Subobject  Class 

User 

Editable? 

title-properties 

panair-title-properties-class 

yes 

run-type-properties 

panair-run-type-properties-class 

yes 

flow-symmetry-properties 

panair-flow-symmetry-properties-class 

yes 

onset-flow-conditions- 

properties 

panair-onset-flow-conditions- 

properties-class 

yes 

reference-data-properties 

panair-reference-data-properties-class 

yes 

networks 

panair-networks-class 

no 

printout-control-properties 

panair-printout-control-properties-class 

yes 

boundary-layer-and- 

velocity-correction-control- 

properties 

panair-boundary-layer-and-velocity- 

correction-control-properties-class 

yes 

liberalized-abutments- 

properties 

panair-liberalized-abutments- 

properties-class 

yes 

The  flight  conditions  for  each  run  of  PANAIR  will  be  determined  from  the  properties 
mach-numbers,  angles-of-attack,  and  sideslip-angles.  A  separate  run  of  PANAIR  will  be 
made  for  each  combination  of  the  values  in  these  properties.  To  make  only  a  single 
PANAJR  run,  each  of  these  properties  should  contain  a  list  with  a  single  value. 


PANAIR  has  an  option  to  find  multiple  solutions  during  a  single  run  for  angles  of  attack 
and  sideslip  angles  close  to  the  compressibility  direction  angles.  This  mode  is  normally 
not  used  by  basic-panair-class.  To  make  a  single  PANAIR  run  with  multiple  solutions, 
at  least  one  of  the  properties  mach-numbers,  angles-of-attack,  and  sideslip-angles  should 
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have  a  value  of  nil.  The  flight  conditions  will  then  be  written  to  the  input  file  based  on 
the  properties  in  the panair-onset-flow-conditions-properties-class  subobject. 


The  results  of  the  PANAIR  runs  are  contained  in  the  property  component-coefficients. 
The  form  of  the  results  is  a  list  of  lists  of  data.  In  each  list,  the  first  list  contains  the  flight 
conditions  and  the  second  list  contains  the  resulting  coefficients.  Each  entry  in  the  list 
has  the  form: 

((mach-number  angle-of-attack  sideslip-angle)  (fx  fy  fz  mx  my  mz  area)). 

The  data  is  read  firom  the  PANAIR  ffinf  output  file  after  each  run. 


Two  logical  paths  are  expected  to  be  available  when  using  the  basic-panair-class.  The 
first,  :panair-path,  should  point  to  the  location  of  the  PANAIR  executable.  The  second, 
:panair-user-data,  should  point  to  the  parent  directory  where  the  data  files  for  PANAIR 
runs  should  be  stored.  This  class  will  automatically  create  subdirectories  under  the  path 
specified  by  :panair-user-data. 


Inherit-ftom: 

(name-generator) 


Properties: 

mach-numbers  A  list  of  values  to  be  used  as  the  Mach  number  input  for  a  PANAIR 

run. 

angles-of-attack  A  list  of  values  to  be  used  as  the  angle  of  attack  input  for  a  PANAIR 

run. 

sideslip-angles  A  Ust  of  values  to  be  used  as  the  sideslip  angle  input  for  a  PANAIR  run. 

body-length  A  reference  vehicle  length.  This  will  be  used  in  the  automatic 

conq)utation  of  values  in  the  panair-rrference-data-properties- 
class  object.  The  default  value  is  1.0. 

max-cross-section-area  A  reference  vehicle  area.  This  will  be  used  in  the  automatic 

computation  of  values  in  the  panair-reference-data-proeprties- 
class  object.  The  default  value  is  1.0. 

component-coefficients  A  list  containing  the  results  of  all  of  the  PANAIR  runs  made.  This 

should  not  be  changed  by  the  user. 


panair-model-name 


This  name  will  be  written  to  the  PANAIR  input  file  and  will  be  used  as 
the  name  of  the  directory  in  which  data  files  are  stored.  The 
default  formula  will  append  the  date  to  the  string  "PANAIR- 
MODEL". 

panair-input-file-name  The  complete  path  and  filename  for  the  input  file  to  PANAIR.  The 

default  value  is  the  panair-model-name  witli  the  extension  ".inp"  in 
the  directory  specified  by  mn-dir.  This  is  the  file  that  is  written  by 
basic-panair-class  before  PANAIR  is  run. 

panair-output-file-name  The  complete  path  and  filename  for  the  main  output  file  fi-om  PANAIR. 

The  default  value  is  the  panair-model-name  with  the  extension 
".out"  in  the  directoiy  specified  by  run-dir.  Note:  This  is  only 
used  when  running  on  a  UNIX  system.  On  Windows  systems,  the 
output  file  name  will  be  "panair.out". 

panair-command  This  property  should  contain  a  string  containing  the  complete  command 

required  to  run  PANAIR. 

run-panair?  Demanding  this  property  will  cause  PANAIR  to  be  run.  The  results 

from  the  run  will  be  stored  in  this  property  and  component- 
coefficients.  They  should  be  read  from 
The  property  contains  the  complete  path  to  the  directory  in  which 

PANAIR  files  will  be  written.  By  default,  this  property  will  get  its 
value  from  the  directory  property  and  automatically  create  the 
directory  if  it  does  not  already  exist.  This  property  should  be 
treated  as  an  output  and  should  not  be  changed  by  the  user. 

directory  This  property  should  contain  the  complete  path  to  the  directory  in 

wliich  PANAIR  files  will  be  written.  The  default  will  be  a 
directory  with  the  name  panair-model-name  in  the  directory 
specified  by  the  : panair-user-data  logical  path.  This  property 
should  be  treated  as  an  input.  The  actual  directory  being  used 
should  be  read  from  the  run-dir  property.  Accessing  that  property 
will  automatically  create  the  directory  if  it  does  not  already  exist. 


Methods: 

write-panair-properties 

write-panair-deck 


This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 
TITLE  data  block  of  the  PANAIR  input  file.  The  strings  contained  in  panair-model- 
name  and  title-lines  will  be  put  in  this  block. 


Inherit-from: 


(panair-properties-class) 


Properties: 

panair-model-name  A  string  which  will  be  put  as  the  first  line  in  the  TITLE  data  block.  The 

default  formula  will  use  the  value  of  the  panair-modeUname  of  the 
parent  basic-panair-class, 

title-lines  A  list  of  string  which  will  be  put,  in  order,  in  the  TITLE  data  block 

following  panair-model-name.  The  default  value  is  nil. 


Methods: 

write-panair-properties 


panair-run-type-properties-class _ [Class] 

This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 
SOLUTION,  DATACHECK,  and  RESTART  data  blocks  of  the  PANAIR  input  file.  The 
type  of  data  block  written  will  be  based  on  the  value  of  the  program-control-mode 
property. 


Inherit-from: 

(panair-properties-class) 


Properties: 

program-control-mode  The  value  of  this  property  determines  the  mode  in  which  PANAIR  will 

be  run.  This  will  determine  which  of  the  other  properties  will  be 
written  into  the  PANAIR  input  file.  Allowed  values  are  'solution, 
'datacheck,  and  'restart.  The  default  value  is  'solution, 
ndtchk  The  NDTCHK  parameter  in  the  PANAIR  input  file.  This  parameter  is 

written  when  program-control-mode  is  'datacheck.  The  default 
value  is  1.0, 

nckusp  The  NCKUSP  parameter  in  the  PANAIR  input  file.  This  parameter  is 

written  when  program-control-mode  is  'restart.  The  default  value 
is  0.0. 
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nckaic 


nckfam 


The  NCKAIC  parameter  in  the  PANAIR  input  file.  This  parameter  is 
written  'fihen  program-control-mode  is  'restart.  The  default  value 
is  1.0. 

The  NCKFAM  parameter  in  the  PANAIR  input  file.  This  parameter  is 
written  when  program-control-mode  is  'restart.  The  default  value 
is  1.0  if  nckaic  =  1.0  and  0.0  otherwise. 


Methods: 

write-panair-properties 


panair-flow-sym  metry-prope  rties-class 


[Class] 


This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 
SYMMETRY  data  block  of  the  PANAIR  input  file. 


Inherit-fi-om: 


(panair-properties-class) 


Properties: 

The  XZPLN  parameter  in  the  PAN  AIR  input  file.  The  default  value  is 
0.0. 

The  XYPLN  parameter  in  the  PAN  AIR  input  file.  The  default  value  is 
0.0. 


Methods: 


write-panair-properties 


panair-onset-flow-conditions-properties-class 


[Class] 


This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 
MACH,  CASES,  ANGLES,  and  YAW  data  blocks  of  the  PANAIR  input  file.  The 
properties  in  this  object  are  only  used  when  the  user  does  not  specify  values  for  the 
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properties  mach-numbers,  angles-of-attack,  and  sideslip-angles.  If  all  three  of  these 
properties  are  specified,  then  the  data  blocks  will  be  written  based  on  their  values  and  the 
properties  of  this  object  will  be  ignored.  If  they  are  not  all  specified,  then  the  data  blocks 
will  be  written  based  on  the  properties  of  this  object. 


The  only  way  a  single  PANAIR  run  may  be  made  with  more  than  one  angle  of  attack  or 
sideslip  angle  is  by  using  the  alpha  and  beta  properties  of  this  object. 


If  the  properties  mach-numbers,  angles-of-attack,  and  sideslip-angles  are  given  values  in 
the  basic-panair-class  object  then  any  values  given  to  properties  of  this  object  will  be 
ignored. 


Inherit-from: 

(panair-properties-class) 


Properties: 

amach  The  Mach  number  at  which  the  simulation  will  be  run.  This  is  the 

AMACH  parameter  in  the  PANAIR  input  file, 
nacase  The  number  of  solution  cases  in  the  PANAIR  run.  This  is  the 

NACASE  parameter  in  the  PANAIR  input  file.  The  default 
formula  is  the  minimum  length  of  the  alpha  and  beta  property  lists, 
alpc  The  angle  of  attack  direction  of  compressibility  effects.  This  is  the 

ALPC  parameter  in  the  PANAIR  input  file. 

alpha  A  list  of  up  to  four  (4)  angles  of  attack  which  will  be  used  to  compute 

multiple  solutions  during  a  single  PANAIR  run.  This  is  the 
ALPHA()  parameter  in  the  PANAIR  input  file.  The  default 
formula  is  a  list  with  a  single  entry  equal  to  the  value  of  alpc. 
betc  The  sideslip  angle  direction  of  compressibility  effects, 

beta  A  list  of  up  to  four  (4)  sideslip  angles  which  will  be  used  to  compute 

multiple  solutions  during  a  single  PANAIR  run.  This  is  the 
BETA()  parameter  in  the  PANAIR  input  file.  The  default  formula 
is  a  list  with  a  single  entry  equal  to  the  value  of  betc. 


Methods: 

write-panair-properties 
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panair-reference-data-properties 

[Class] 

This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 
REFERENCE  data  block  of  the  PANAIR  input  file. 


Inherit-ffom; 

(panair-properties-class) 


Properties: 

body-length 

xref 

yref 

zref 

sref 

bref 

cref 

dref 


The  length  of  the  body.  Tlie  default  formula  will  get  this  value  from  the 
body-length  property  of  the  parent  basic-panair-class  and  should 
not  be  changed.  This  property  is  used  directly  by  PANAIR. 

The  X  component  of  the  moment  reference  location  corresponding  to 
the  XREF  parameter  in  the  PANAIR  input  file.  The  default  value 
is  52%  of  the  body-length. 

The  y  component  of  the  moment  reference  location  corresponding  to 
the  YREF  parameter  in  the  PANAIR  input  file.  The  default  value 
is  0.0. 

The  z  component  of  the  moment  reference  location  corresponding  to 
the  ZREF  parameter  in  the  PANAIR  input  file.  The  default  value 
is  0.0. 

The  frill  airplane  reference  area  corresponding  to  the  SREF  parameter 
in  the  PANAIR  input  file.  The  default  formula  will  get  this  value 
from  the  max-cross-section-area  property  of  the  parent  basic- 
panair-class. 

The  reference  length  for  MX  corresponding  to  the  BREF  parameter  in 
the  PAN  AIR  input  file.  The  default  formula  will  compute  the 
radius  of  a  circle  with  area  equal  to  sref. 

The  reference  length  for  MY  corresponding  to  the  CREF  parameter  in 
the  PANAIR  input  file.  The  default  formula  will  use  the  value  of 
bref. 

The  reference  length  for  MZ  corresponding  to  the  DREF  parameter  in 
the  P ANAIR  input  file.  The  default  formula  will  use  the  value  of 
bref. 


Methods: 


write-panair-properties 


76 


panair-printout-control-properties-class 

[Class] 

This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 

PRINTOUT  data  block  of  the  PANAIR  input  file. 

Inherit-from: 

(panair-properties-class) 

Properties: 

isings 
igeomp 
isingp 
icontp 
ibconp 
iedgep 
ipraic 
nexdgn 
ioutpr 
ildncpr 
icostp 

Methods: 

write-panair-properties 

panair-boundary-layer-and-velocity-correction-control-properties-class _ [Class] 

This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 


Corresponds  to  the  ISINGS  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  IGEOMP  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  ISINGP  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  ICONTP  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  IBCONP  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  IEDGEP  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  IPRAIC  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  NEXDGN  parameter  in  the  PANAIR  input  file. 

The  default  value  is  0.0. 

Corresponds  to  the  lOPTR  parameter  in  the  PANAIR  input  file.  The 
default  value  is  1.0. 

Corresponds  to  the  IFMCPR  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 

Corresponds  to  the  ICOSTP  parameter  in  the  PANAIR  input  file.  The 
default  value  is  0.0. 
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BOUNDARY  and  VELOCITY  data  blocks  of  the  PANAIR  input  file.  The  type  of  data 
block  written  will  be  based  on  the  value  of  the  bl-or-ivcorr?  property. 


Inherit-from: 

(panair-properties-class) 


Properties: 


bl-or-ivcorr? 


ivcorr-boxmdary-layer 

ivcorr-velocity-correction 


This  property  determines  whether  the  BOUNDARY  or  VELOCITY 
data  block  will  be  written  to  the  PANAIR  input  file.  Allowed 
values  are  'boundary  and  'velocity.  The  default  value  is  'boundary. 
The  value  of  this  property  will  be  used  as  the  IVCORR  parameter  in  the 
PANAIR  input  file  when  bl-or-ivcorr?  has  a  value  of  'boundary. 
The  default  value  is  0.0. 

The  value  of  this  property  \vill  be  used  as  the  IVCORR  parameter  in  the 
PANAIR  input  file  when  bl-or-ivcoir?  has  a  value  of  'velocity. 

The  default  value  is  0.0. 


Methods: 

write-panair-properti  es 

[Class] 

This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 
EAT  data  block  of  the  PANAIR  input  file.  The  property  liberalized-abutments?  is  used 
to  indicate  whether  this  data  block  should  be  written  to  the  file  or  not. 


panair-liberalized-abutments-properties-class 


Inherit-fi-om: 

(panair-properties-class) 


Properties: 


liberalized-abutments?  When  this  property  has  a  value  of  t,  the  EAT  data  block  will  be  written 

to  the  PANAIR  input  file.  The  default  value  is  nil. 

epsgeo  The  EPSGEO  parameter  in  the  PANAIR  input  file.  The  default  value  is 

0.1. 

igeoin  The  IGEOIN  parameter  in  the  PANAIR  input  file.  The  default  value  of 

nil  will  create  a  blank  entry  m  the  file. 

igeout  The  IGEOUT  parameter  in  the  PANAIR  input  file.  The  default  value 

of  nil  will  create  a  blank  entry  in  the  file. 

nwxref  The  NWXREF  parameter  in  the  PANAIR  input  file.  The  default  value 

of  nil  will  create  a  blank  entry  in  the  file. 

triint  The  TRIINT  parameter  in  the  PANAIR  input  file.  The  default  value  of 

nil  will  create  a  blank  entry  in  the  file. 

iabsum  The  lABSUM  parameter  in  the  PANAIR  input  file.  The  default  value 

is  0.0. 


Methods: 

write-panair-properties 


panair-networks-class _ [Class] 

This  class  is  used  as  a  subobject  of  basic-panair-class  and  provides  information  for  the 
POINTS  data  blocks  of  the  PANAIR  input  file. 


The  network-list  property  should  contain  a  list  of  references  to  instances  of  class  panair- 
network-class.  By  default,  the  formula  for  this  property  will  find  all  instances  of  panair- 
network-class  that  are  in  the  branch  of  the  model  tree  headed  by  panair-networks-class. 
Any  networks  that  are  added  beneath  this  object  will  automatically  be  added  to  the  list. 
Alternately,  networks  may  be  placed  anywhere  in  the  tree  and  the  formula  for  network-list 
may  be  changed  appropriately. 


Inherit-from: 

(panair-properties-class) 


Properties: 
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network-list 


network-lookup-table 


network-ids 


This  property  should  contain  a  list  of  references  to  instances  of  panair- 
network-class  which  represent  the  actual  networks  to  be  used  in  the 
analysis.  The  default  formula  will  fmd  all  instances  of panair- 
netw’ork-class  which  are  under  the  panair-networks-class .  If  this 
default  behavior  is  acceptable,  the  formula  for  this  property  should 
not  be  changed. 

This  property  contains  a  list  associating  instances  of  panair-network- 
class  and  their  network  ids.  This  property  should  not  be  changed 
by  the  user. 

This  property  contains  a  list  of  network  ids  corresponding  to  the  objects 
in  network-list.  The  individual  network  objects  will  get  their  ids 
from  this  property  (through  the  method  get~network-id).  By 
default,  this  property  will  contain  a  list  of  consecutive  integers 
beginning  with  1 .  This  property  should  not  normally  be  changed 
by  the  user. 


Methods: 

write-panair-properties 

get-network-id 


panair-network-ciass 


[Class] 


This  class  is  used  to  represent  one  network  in  the  PANAIR  analysis.  Information  in  this 
object  will  be  used  to  create  a  POINTS  data  block  in  the  PANAIR  input  file. 


Typically,  instances  of  this  class  will  be  children  of  an  instance  of  panair-networks-class 
but  they  may  appear  anywhere  in  the  model  tree.  If  they  do  not  appear  beneath  the 
panair-networks-class  instance,  then  the  network-list  of  the  panair-networks-class 
instance  will  need  to  be  changed  to  reflect  this. 


The  source-object  property  should  point  to  an  instance  of  an  object  fi-om  which  mesh 
geometry  can  be  found. 


Inherit- fi-om: 

(web-surface-ffom-points-object  panair-properties-class) 
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Properties: 

source-object 

networks-object 

network-id 

run-dir 

netname 

cpnorm 

dnsmsh 

dn 

dm 

betl 

betl-t 

kn 

nm 

nn 


This  property  should  point  to  an  instance  of  an  object  which  can 
provide  network  mesh  information.  The  default  value  is  nil. 

This  property  should  point  to  an  instance  of  panair-networks-class.  By 
default,  it  will  look  up  in  the  tree  from  the  panair-network-class  to 
find  an  instance  of panair-networks-class. 

This  property  contains  the  id  for  this  network.  By  default,  this  will  be 
found  by  calling  the  method  get-network-id  on  the  instance  of 
panair-networks-class  referenced  in  networks-object.  This  should 
normally  not  be  changed  by  the  user. 

The  directory  in  which  files  should  be  written.  By  default,  this  property 
will  get  its  value  from  a  property  with  the  same  name  in  and 
instance  above  it  in  the  tree. 

By  default,  this  will  be  a  string  version  of  the  network-id.  This  name  is 
written  as  NETNAME  to  the  PANAIR  input  file. 

Describes  the  mesh  surface  normals  and  corresponds  to  the  CPNORM 
parameter  in  the  PANAIR  input  file.  The  default  value  is  2.0. 

Determines  whether  panel  mesh  density  will  be  modified  from  that 

given  by  nm  and  nn  and  corresponds  to  the  DNSMSH  parameter  in 
the  PANAI5.  input  file.  When  dnsmsh  is  1.0,  the  parameters  dn 
and  dm  will  be  written  to  the  input  file.  When  dsnmsh  is  0.0,  they 
will  not.  The  default  value  is  0.0. 

Density  factor  which  changes  the  number  of  columns  in  the  mesh 

corresponding  to  the  DN  parameter  in  the  PANAIR  input  file.  This 
parameter  will  only  be  written  to  the  file  when  dnsmsh  is  1.0.  The 
default  value  is  1.0. 

Density  factor  which  changes  the  number  of  rows  in  the  mesh 

corresponding  to  the  DN  parameter  in  the  PANAIR  input  file.  This 
parameter  will  only  be  written  to  the  file  when  dnsmsh  is  1 .0.  The 
default  value  is  1.0. 

Two-dimensional  mass  flux  for  each  solution  corresponding  to  BETL  in 
the  PANAIR  input  file.  The  value  of  this  property  should  be  a  list 
of  values  corresponding  to  the  cases  in  the  panair-onset-flow- 
conditions-property-class.  This  property  will  be  used  to  create  the 
INFLOW  data  block  in  the  input  file  and  is  only  written  when  kt  is 
either  9,  4,  or  14. 

Twice  the  surface  thickness  slope  for  each  solution  corresponding  to 
BETL  ia  the  PANAIR  input  file.  The  value  of  this  property  should 
be  a  list  of  values  corresponding  to  the  cases  in  the  panair-onset- 
flow-conditions-property-class .  This  property  will  be  used  to 
create  the  SIMULATED  THICKENSS  data  block  in  the  input  file 
and  is  only  written  when  kt  is  either  2  or  12  and  when  tkw  is  1 .0. 

The  number  of  networks  in  the  group  represented  by  this  object 

corresponding  to  the  KN  parameter  in  the  PAN  AIR  input  file.  The 
default  value  is  1.0  and  should  not  be  changed  by  the  user. 

The  number  of  rows  in  the  network  corresponding  to  the  NM  parameter 
in  the  PANAIR  input  file.  The  value  of  this  property  is  determined 
automatically  based  on  the  value  of points-list  and  should  not  be 
changed  by  the  user. 

The  number  of  columns  in  the  network  corresponding  to  the  NN 

parameter  in  the  PANAIR  input  file.  The  value  of  this  property  is 
determined  automatically  based  on  the  value  of  points-list  and 
should  not  be  changed  by  the  user. 
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“■panels  The  total  number  ofpanels  in  the  network.  This  is  computed 

automatically  based  on  nm  and  m  and  should  not  be  changed  by 
the  user. 

Defines  the  boundary  condition  type  for  the  mesh  and  corresponds  to 
the  KT  parameter  in  the  PANAIR  input  file.  The  default  value  is 
1.0. 

tkw  Corresponds  to  the  TKW  parameter  in  the  PANAIR  input  file.  The 

default  value  of  nil  will  leave  this  blank  in  the  file, 
resultant-number-of-panels  The  total  number  of  panels  in  the  network  including  the  effects  of 

the  density  properties  dn  and  dm.  This  is  computed  automatically 
and  should  not  be  changed  by  the  user. 

points-list  A  list  of  lists  of  points  specifying  the  mesh  for  this  network.  When 

source-object  is  given,  these  points  will  be  determined  from  the 
specified  object  and  this  property  should  not  be  changed  by  the 
user.  These  points  will  be  written  as  X  Y  Z  data  in  the  PANAIR 
input  file. 


nodes-file 


con-file 


use-files? 


cleanup? 


This  property  is  used  to  create  the  network  geometry  if  required 
(primarily  for  display  purposes).  It  comes  from  the  inheritance 
from  web-suiface-from-points-object.  The  default  formula  will 
create  a  file  in  the  run-dir  directory.  It  does  not  normally  need  to 
be  changed  by  the  user. 

This  property  is  used  to  create  the  network  geometry  if  required 
(primarily  for  display  purposes).  It  comes  from  the  inheritance 
from  web-surface-from-points-object.  The  default  formula  will 
create  a  file  in  the  run-dir  directory.  It  does  not  normally  need  to 
be  changed  by  the  user. 

This  property  is  used  to  create  the  network  geometry  if  required 
(primarily  for  display  purposes).  It  comes  from  the  inheritance 
from  web-surface-from-points-object.  It  does  not  normally  need  to 
be  changed  by  the  user. 

This  property  is  used  to  create  the  network  geometry  if  required 
(primarily  for  display  purposes).  It  comes  from  the  inheritance 
from  web-surface-from-points-object.  It  does  not  normally  need  to 
be  changed  by  the  user. 


Methods: 

generate-panair-network-mesh-points 

write-panair-properties 


This  class  provides  a  common  superclass  for  all  PANAIR  classes  to  inherit  from  It  adds 
no  additional  functionality. 


Mierit-from: 


(object) 


PANAIR  Class  with  Common  Aerodynamic  Coefficients  Interface 


panair-class 


[Class] 


This  class  combines  the  PANAIR  analysis  of  basic-panair-class  with  the  common 
interface  for  accessing  aerodynamic  coefficients  provided  by  aerodynamic-coefficients- 
source-class.  This  will  allow  any  other  objects  or  applications  which  require  the 
aerodynamic  coefficients  results  from  PANAIR  to  access  them  in  a  standard  way.  These 
can  be  accessed  using  the  get-coefficients  method  and  the  key  and  coefficient  symbols 
listed  below. 


This  class  also  implements  interfaces  to  flight  condition  and  body  geometry  objects.  If 
these  objects  are  referenced,  then  many  of  the  properties  of  panair-class  will  be  computed 
automatically.  The  panair-class  will  ignore  the  state  of  the  angle-mode  property  of  the 
jlight-conditions-object  and  always  uses  the  angles-of-attack  and  sideslip-angles  from  the 
flight-conditions-object. 


The  aerodynamic  coefficients  are  accessed  using  the  keys  'M,  'alpha,  and  'beta 
summarized  in  this  table: 


Key 

Symbol 

Label 

Description 

Range  in  Property: 

Mach  number 

'M 

"Mach  Number" 

mach-numbers 

angle  of  attack 

'alpha 

"alpha" 

"Angle  of 

Attack" 

angles-of-attack 

sideslip  angle 

■beta 

"beta" 

"Sideslip  Angle" 

sideslip-angles 

The  aerodynamic  coefficients  available  in  panair-class  are  summarized  in  this  table: 


Coefficient 

Symbol 

PANAIR  Output 

Value 

'CA 

fx 

■CY 

fy 

'CN 

fz 

'CSL 

mx 

'CSM 

my 

■CSN 

mz 

Inherit-from: 

(basic-panair-class  aerodynamic-coefficients-source-class) 


Properties: 

flight-conditions-object  If  this  property  contains  a  ?Ae-reference  to  an  instance  offlight- 

conditions-class ,  then  the  values  of  mach-numbers,  angles-of- 
attack,  and  sideslip-angles  will  be  taken  from  that  object  and  do 
not  have  to  be  set  in  this  object.  The  default  value  of  nil  indicates 
that  the  properties  need  to  be  set  in  this  object. 

body-geometry-interface-obj  ect  If  this  property  contains  a  /Ae-reference  to  an  instance  of  body- 

geometry-interf ace-class,  then  the  values  of  body-length  and  max- 
cross-section-area  will  be  taken  from  that  object  and  do  not  have 
to  be  set  in  this  object.  The  default  value  of  nil  indicates  that  the 
properties  need  to  be  set  in  this  object. 

body-length  The  reference  vehicle  length.  If  a  body-geometry-interface-obj  ect  is 

specified,  then  the  value  of  this  property  will  be  taken  from  the 
body-length  property  of  that  object.  Otherwise,  it  must  be  set  here. 
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max-cross-section-area  The  reference  vehicle  area.  If  a  body-geometry-interface-object  is 

specified,  then  the  value  of  this  property  will  be  taken  from  the 
body-max-cs-area  of  that  object.  Otherwise,  it  must  be  set  here. 


mach-numbers 

angles-of-attack 

sideslip-angles 

ac-key-symbols 

ac-key-labels 

ac-key-descriptions 

ac-key-ranges 

ac-coefficient-symbols 


A  list  of  values  to  be  used  as  the  Mach  number  input  for  a  PANAIR 
run.  If  2iflight-conditions-object  is  specified,  then  the  value  of  this 
property  will  be  taken  from  the  mach-numbers  property  of  this 
object.  Otherwise,  it  must  be  set  here. 

A  list  of  values  to  be  used  as  the  angle  of  attack  input  for  a  PANAIR 
run.  If  a  flight-conditions-object  is  specified,  then  the  value  of  this 
property  will  be  taken  from  the  angles-of-attack  property  of  this 
object.  Otherwise,  it  must  be  set  here. 

A  list  of  values  to  be  used  as  the  sideslip  angle  input  for  a  PANAIR  run. 
If  di  flight-conditions-object  is  specified,  then  the  value  of  this 
property  will  be  taken  from  the  sideslip-angles  property  of  this 
object.  Otherwise,  it  must  be  set  here. 

A  list  of  the  keys  used  to  access  the  aerodynamic  coefficients  in  the 
panair-class.  This  should  not  be  changed  by  the  user. 

A  list  of  the  labels  of  the  keys  in  panair-class.  This  should  not  be 
changed  by  the  user. 

A  list  of  the  descriptions  of  the  keys  in  panair-class.  This  should  not 
be  changed  by  the  user. 

A  list  of  the  key  ranges  in  panair-class.  This  is  based  on  the  mach- 
numbers,  angles-of-attack,  and  sideslip-angles  properties  and 
should  not  be  changed  by  the  user. 

A  list  of  the  coefficient  symbols  in  panair-class.  This  should  not  be 
changed  by  the  user. 
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Appendix  5:  AML  Dracon  Interface  Documentation 


generate-drakon-materials-file _ 

This  function  generates  the  materials  file  needed  for  the  Dracon  analysis. 
Format: 


[Fxinction] 


(generate-drakon-materials-file  file-name  &key  drakon-path) 

Arguments: 

file-name  String  specifying  the  materials  file  name 

drakon-path  String  specifying  the  path  to  the  drakon  directory.  Default  is  (logical-path 
:drakon-binaries) 


convert-aml-mesh-ascii-Files-to-drakon-binary 


[Function] 


This  function  converts  the  AML  mesh  ASCII  files  to  drakon  binary  format  for  the  Dracon 
analysis. 

Format: 


(convert-aml-mesh-ascii-files-to-drakon-binary 


Arguments: 

crd-file  n-nodes  con-file  n-elements  directory  element-type 

&key  drakon-path) 

crd-file 

String  specifying  the  node  coordinates  file  name 

n-nodes 

Number  of  nodes  in  mesh 

con-file 

String  specifying  the  node  connectivity  file  name 

n-elements 

Number  of  elements  in  mesh 
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directory 

element-type 

drakon-path 


String  specifying  the  directory  path 

String  or  symbol  specifying  Drakon  element  type 

String  specifying  the  path  to  the  drakon  directory.  Default  is  (logical-path 
:drakon-binaries) 


convert-aml-loads-ascii-file-to-drakon-binary _  [Function] 

This  function  converts  the  AML  loads  ASCII  files  to  drakon  binary  format  for  the  Dracon 
analysis. 

Format: 

(convert-aml-loads-ascii-file-to-drakon-binary 
loads-file  directory 
&key  drakon-path 
) 

Arguments: 

loads-file  String  specifying  the  loads  file  name 
directory  String  specifying  the  directory  path 

drakon-path  String  specifying  the  path  to  the  drakon  directory.  Default  is  (logical-path 
:drakon-binaries) 

convert-aml-fixed-nodes-ascii-file-to-drakon-binary _  [Function] 

This  function  converts  the  AML  constraints  ASCII  files  to  drakon  binary  format  for  the 
Dracon  analysis. 

Format: 

(convert-aml-fixed-nodes-ascii-file-to-drakon-binary 
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fixed-nodes-file  directory 
&key  drakon-path 
) 

Arguments: 

fixed-nodes-file  String  specifying  the  fixed  nodes  file  name 
directory  String  specifying  the  directory  path 

drakon-path  String  specifying  the  path  to  the  drakon  directory.  Default  is 

(logical-path  :drakon-binaries) 


convert-aml-zero-thickness-elementS’ascii-file’to-drakon-binary 


[Function] 


This  function  converts  the  AML  zero  thickness  ASCII  files  to  drakon  binary  format  for 
the  Dracon  analysis. 


Format: 


(convert-aml-zero-thickness-elements-ascii-file-to-drakon-binary 
zero-thickness-elements-file  directory 
&key  drakon-path 


) 


Arguments: 

zero-thickness-elements-file  String  specifying  the  zero  thickness  elements  file  name 
directory  String  specifying  the  directory  path 

drakon-path  String  specifying  the  path  to  the  drakon  directory.  Default 

is  (logical-path  :drakon-binaries) 


88 


run-drakon 

[Function] 

This  function  runs  for  the  Dracon  analysis. 

Format: 

(run-drakon 

analysis-type  directory  num-iterations  load-cases 

&key  drakon-path 

) 


Arguments: 

analysis-type 

directory 

num-iterations 

load-cases 

drakon-path 


Options  are  :  analysis  or  :  optimization  to  either  run  the  Drakon 
structural  analysis  or  the  Drakon  Optimization 

String  specifying  the  directory  path 

Number  of  iterations  for  to  run  in  the  optimization 

List  of  load  values 

String  specifying  the  path  to  the  drakon  directory.  Default  is 
(logical-path  :drakon-binaries) 


convert-drakon-binaiy-result-files-to-aml-ascii _  [Function] 

This  function  converts  the  Drakon  binary  results  files  to  ASCII  files  for  analysis. 

Format: 

(convert-drakon-binary-result-files-to-aml-ascii 

directory  aml-displ-prefix  ami-stress-prefix 
&key  drakon-path  n-load-cases 
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) 

Arguments: 

directory 

String  specifying  the  directory  path 

aml-displ-prefix 

Prefix  of  the  displacement  result  in  string  format. 

ami-stress-prefix 

Prefix  of  the  stress  result  in  string  format. 

drakon-path 

String  specifying  the  path  to  the  drakon  directory.  Default  is 
(logical-path  :drakon-binaries) 

n-load-cases 

Number  of  load  cases  in  the  file.  Defaults  to  1 . 

drakon-interface-class 

rClassT 

This  class  provides  the  necessary  objects  and  properties  to  interface  AML  with  the 
Drakon  stress  and  optimization  analysis. 


Inherit-ffom:  name-generator 
Properties: 


mesh-query 


fixed-nodes-query 


zero-thickness-elements-query 


loads-query 


directory 


analysis-type 


Mesh  query  instance  for  the  stmcture  being 
analyzed.  Defaults  to  (default  nil) 


Mesh  query  instance  of  the  constrained  nodes. 
Defaults  to  (default  nil) 

Mesh  query  instance  of  the  nodes  that  have  zero 
thickness  such  as  holes  or  cutouts.  Defaults  to 
(default  nil) 

Mesh  query  instance  of  the  loaded  nodes.  Defaults 
to  (default  nil) 

String  specifying  the  directory  path  where  the 
analysis  files  are  located.  Defaults  to  (default  nil) 

Options  are  lanalysis  or  :optimization  to  either  run 
the  Drakon  stmctural  analysis  or  the  Drakon 
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Optimization  analysis  Defaults  to  (default  nil) 


n-iterations 


load-cases 


element-type 


drakon-binaries-path 


generate-materials-file? 


convert-mesh? 


Number  of  iterations  for  to  run  in  the  optimization 
Defaults  to  (default  1) 

Number  of  load  cases  in  the  analysis.  Defaults  to 
(default  1) 

Element  type  used  in  the  analysis.  3  represents  a 
three  sided  element,  5  represents  a  membrane-quad 
element,  and  6  represents  a  sandwich  element. 
Defaults  to  (default  5) 

String  specifying  the  directory  path  to  the  Drakon 
binaries.  Defaults  to  (logical-path  .drakon- 
binaries) 

Demanding  this  property  will  generate  the  materials 
file  called  mater.dat  in  the  directory  specified  by  the 
directory  property 

Demanding  this  property  will  convert  the  mesh  files 
from  AML  format  to  Drakon  binary  format 


convert-loads? 


Demanding  this  property  will  convert  the  load  files 
from  AML  format  to  Drakon  binary  format 


convert-fixed-nodes? 


Demanding  this  property  will  convert  the  constraint 
files  from  AML  format  to  Drakon  binary  format 


convert-zero-thickness-elements?  Demanding  this  property  will  convert  the  zero¬ 
thickness  files  from  AML  format  to  Drakon  binary 
format 


run-drakon? 


convert-results? 


displacement-output-file 


Demanding  this  property  will  (if  needed)  convert 
the  mesh,  generate  the  materials  file,  convert  the 
loads,  convert  the  fixed  nodes,  convert  the  zero 
thickness  elements,  run  the  specified  analysis 
depending  on  the  analysis-type  property 

Demanding  this  property  will  run  Drakon  if 
necessary  and  convert  the  output  files  to  AML 
format  ASCII  files 

File  containing  the  displacement  results.  Defaults 
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to  (nth  0  (nth  0  '^convert-results?)) 

stress-output-file 

File  containing  the  stress  results.  Defaults  to  (nth  0 
(nth  1  '^convert-results?)) 

Subobjects; 

drakon-results-tables 

An  instance  of  mesh-with-color-mapping-tables- 
class,  this  object  collects  the  data  and  results  from 
the  Drakon  analysis  and  is  used  in  the  displacements 
and  stress  visualizations. 

displacements 

A  series  of  mesh-with-color-mapping-class  objects 
showing  the  displacements  from  the  Drakon 
analysis 

equivalent-stress 

An  instance  of  mesh-with-color-mapping-class 
showing  the  equivalent  stress  output  from  the 
Drakon  analysis 

Icf-equivalent-stress 

An  instance  of  mesh-with-color-mapping-class 
showing  the  Icf  equivalent  stress  output  from  the 
Drakon  analysis 

Icf-equivalent-stress- 1 

An  instance  of  mesh-with-color-mapping-class 
showing  the  Icf  equivalent  stress  1  output  from  the 
Drakon  analysis 

lcf-equivalent-stress-2 

An  instance  of  mesh-with-color-mapping-class 
showing  the  Icf  equivalent  stress  2  output  from  the 
Drakon  analysis 

thickness 

An  instance  of  mesh-with-color-mapping-class 
showing  the  thickness  distribution  output  from  the 
Drakon  analysis 

stress-vectors 

An  instance  of  mesh-with-color-mapping-class 
showing  the  vector  plot  of  the  stress  output  from  the 
Drakon  analysis 

Drakon  intertace  Examples  . . 

These  classes  are  provided 

as  an  example  to  demonstrate  the  AML/Drakon  interface.  The 
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data  files  can  be  found  electronically  in  the  AML/Drakon  interface  system. 

(define- class  drakon-sandwhich-test 
: inherit-from  (drakon-interf ace-class  ) 

: properties  ( 

directory  "c:  WtempWdrakon-sandwichW" 

aml-crd-file  (logical-path  ^directory  "model. crd") 

aml-con-file  (logical-path  “^directory  "model. con") 

aml-loads-f  ile  (logical-path  '^directory  "model .  loads" ) 

aml-f ixed-nodes-f ile  (logical-path  ^directory  "model . displ" ) 

element-type  (default  6) 

) 

) 

(define- cl ass  drakon-quadmesh-test 

: inherit-from  (drakon-interf ace-class ) 

:properties  ( 

directory  "c:  WtempWdrakon-quadW" 

aml-crd-file  (logical-path  '^directory  "model,  crd") 

aml-con-file  (logical-path  ^directory  "model. con") 

aml-loads-f ile  (logical-path  ^directory  "model . loads" ) 

aml-f ixed-nodes-f ile  (logical-path  ^directory  "model . displ" ) 

element-type  (default  5) 

) 

) 
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Appendix  6: 

General  description  of  the  sandwich  plate  element  used  in  AML 

Alexander  Danilin  —  Samara  State  Aerospace  University 
Terrence  A.  Weisshaar- Purdue  University 


The  sandwich  panel  element  used  by  AML 
is  shown  in  Figure  1.  This  element  is  a 
special  sandwich  plate  developed  at 
Samara  State  Aerospace  University, 
Samara,  Russia,  especially  for  structural 
design  optimization;  its  development  will 
be  summarized  here  so  that  a  user  can 
understand  the  assumptions  used  to  create 
the  element.  This  element  consists  of  two 
isotropic  membrane  skins  with  a 
continuous  filler  or  core  between  them. 
This  element  resists  bending,  twist  and 
shear  loads. 


The  projection  of  the  element  to  the  x-z  plane  has  the  shape  of  an  arbitrary  quadrilateral. 
The  lines  cormecting  the  top  and  bottom  surfaces  of  the  sandwich  are  parallel  to  the  y- 
axis  shown  in  Figure  1. 


The  filler  core  is  relatively  rigid  in  the  transverse  (y)  direction  so  that  normal  strains  in 
the  y-direction  are  veiy  small.  The  assumption  about  filler  core  incompressibility  in  the 
transverse  direction  simplifies  the  development  of  the  element  stiffhess  matrix  and 
reduces  the  number  of  degrees  of  freedom.  The  core  is  shear  deformable  and  distorts  as  it 
resists  shear  stress  and  transmits  these  loads  between  the  top  and  bottom  skins.  This 
shear  deformation  behavior  may  be  isotropic  or  orthotropic.  The  stiffhess  of  this  filler 
core  is  expressed  as  a  matrix 


G  = 


(1) 
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Gyz  and  Gyx  are  the  shear  moduli  of  the  filler  core  in  the  y-z  plane  and  x-y  plane, 
respectively. 


The  nodes  of  the  filler  element  portion  are  placed  at  the  middle  of  core  element  edges  on 
the  y-axis,  as  indicated  in  Figure  1.  Each  node  has  five  degrees  of  freedom:  three 
displacements  (u,  w,  v)  and  two  angles  and  \\f).  The  element  skin  thicknesses  are  6b 
and  5h,  the  modulus  of  elasticity  is  E  and  the  Poisson's  ratio  of  the  skin  material  is  p.  For 
each  node  the  coordinates  x,  y,  z  and  element  height  2h  are  known. 


The  skin  itself  can  have  curvature.  For  this  reason,  each  skin  panel  is  divided  into  four 
triangles,  as  shown  in  Figure  2.  In  the  element  derivation  the  panel  stiffiiess  matrix  has  a 
contribution  fi-om  the  skin  that  is  accounted  for  by  summing  the  individual  stiffness 
matrices  of  the  triangles.  The  coordinates  of  outside  nodes  determine  the  coordinates  of 
the  interior  node.  The  selection  of  this  skin  model  is  made  for  the  several  reasons. 


First  of  all,  the  triangle  is  the  simplest  membrane  element  for  modeling  an  isotropic  skin, 
therefore  creation  of  a  stiffness  matrix 
and  subsequent  programming  are  greatly 
simplified. 


The  introduction  of  an  interior  node  and 
definition  of  its  position  is  accomplished 
using  a  least  squares  method;  this  allows 
careful  approximation  of  the  median 
surface  of  the  skin  using  the  four 
triangles. 


Stiffiiess  matrix  of  skin  panels 


To  illustrate  the  features  of  the  element  development,  let's  consider  the  upper  skin  panel 
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shown  in  Figure  2.  Its  coordinates  on  the  y-axis  are  given  by 


Hi=yi+(hi+0.5d^)  i  =  12,3,4,  (2) 


Coordinates  of  the  interior  point  5  are  calculated 
from  a  least  squares  method  using  coordinates  of 
the  other  four  nodes  of  the  upper  skin  element. 
To  solve  for  the  x-axis  coordinate  it  is  necessary 

4 

to  minimize  a  function  f  (x^  )  =  Y_^(\x^  • 

i=l 

Equating  to  zero  the  derivative  of/fx^;  with 
respect  to  X5  and  solving  this  equation,  we  find 


(3) 


The  coordinates  Z5  and  H5  are  similarly  calculated. 


To  understand  the  development  of  the  upper  skin  stiffhess  matrix,  consider  a  triangle  125 
in  Figure  2.  Enter  a  local  coordinate  system  in  the  plane  of  a  triangle  with  the  beginning 
at  the  point  1.  An  axis  h  is  placed  through  link  1-2,  and  an  axis  x  is  placed  perpendicular 
to  h.  The  length  of  segment  1-2  is  then 


+  Z2j 


(4) 


Where  X21  =  X2  -  Xi;  Z21  =  Z2  -  Zi;  etc. 


Direction  cosines  of  the  axis  h  with  respect  to  axis  x,y,z  are  as  follows 


For  the  definition  of  direction  cosines  of  an  axis  x  from  point  5  we  drop  a  perpendicular 
to  the  axis  h.  The  length  of  segment  1-6  is 


di6  =  li2  X51  +  fni2  H51  +  ni2  Z5h  (6) 


and  the  length  of  a  segment  6-5  is 


Direction  cosines  of  the  axis  x  are 


Local  nodal  coordinates  of  the  triangle  are  written  as 


The  displacements  inside  the  triangle  are  written  as 


u -ao+a,^  +  a27],  w  =bQ+b,^  +  b2ri  (10) 


In  a  matrix  form  these  are  written  as 


{!|=[4W(ii) 

“2  ,  r^i-  ^  ^  ^  ^ 

^0  0  0  0  1  ^  rj 

Using  boundary  conditions,  we  compute  the  displacements  of  the  vertices  of  the  triangle 


U=D-{a]  (12) 


where 


Ui 
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Vs, 

Solving  the  matrix  equation  (12)  and  substituting  this  expression  into  Eqn.  (1 1),  we  find 


\^^  =  [d][DYu.  (13) 


Strains  in  the  triangular  panel  are  then  found  to  be 


r  _ 


du 

h 

dw 

^ri 

drj 

7  , 

dw  du 
ds  dt] 

(14) 


or 

s  =  b-U  (15) 


where 
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0 

~^2I 

(16) 

-^52 

^52 

^5/ 

-75/ 

-^5/ 

V2I 

and  2  A,2s=  4^2121 -^2iV52  (17) 


Translational  displacements  in  the  plane  of  a  triangle  are  calculated  as 


U=W  (18) 


where 


X  0  0 

0  I  0 
0  0  X 


Translations  {w  w  v}^  are  computed  using  translations  \u  w  q) 


u  =  u-(ph' ;  w  =  w  -  (pW;  v  =  v 


(19) 


where  h'  =  h  +  0.5Si^  (20) 


Nodal  displacements  are 
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where 

U  =  {u,  Wj  (p,  y/,  Vj  U2  (p2  W2  ^2 


Doing  this  for  other  triangles  produces  a 
banded  B  matrix  like  that  shown  in  Figure  4. 


Substituting  Eqn.  (13)  into  Eqn.  (15)  and 
solving  Eqns.  (21)  and  (22),  we  calculate 
strains  and  stress  in  the  triangle  125  as 


Ui  W3  (Pi  Vi  V3  U4  W4  (p^  vJ 


Figure  4  -  Banded  B  matrix 


£  =  LU, 


(23) 


or  =  {a^cT^a^,^\=K-L-U,  (24) 


where  L  =  bAnB, 


1 

0 


0 

0 

2 


(25) 


The  stiffness  matrix  contribution  for  an  element  is  obtained  by  integration  of  the 

expression  iJ k  L  over  the  element  volume.  For  the  triangular  panel  125  the  stiffness 
matrix  is  written  as 

K  =  L  1  (26) 


The  stiffness  matrix  of  the  upper  skin  panel  is  obtained  by  summation.  The  stiffness 
matrices  of  the  four  triangles  are  computed,  using  equations  similar  to  Eqns.  (4)  -  (26), 
and  then  summed. 


The  stifjfiiess  matrix  of  the  lower  panel  is  computed  by  the  same  formulas.  To  do  this  it  is 
necessary  to  change  the  sign  before  brackets  in  Eqn.  (2)  and  before  hj  in  Eqn.  (19)  and  to 
substitute  instead  of  in  Eqn.  (2)  and  Eqn.  (20). 


Skin  panel  stresses 


We  calculate  panel  stresses  by  first  substituting  the  coordinates  of  panel  nodes 
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Y  =  C^(CC^  )-^CY  (27) 


h=C^(CC'^  )-‘Ch  (28) 


where  are  the  coordinates  of  the  plane  panel  and 

h={hjh2h^h4]]  h  =  {hih2h3h^}] 

1111 
I 

coordinates  of  the  curved  panel,  and  C  = 


are 


The  stresses  in  each  triangle  are  defined  by  Eqn.  (24).  Thus  in  the  formulas  for  an 
evaluation  of  the  matrices  B  also  it  is  necessary  to  substitute  coordinates  obtained  fi-om 
Eqns.  (27)  and  (23).  The  stresses  in  the  panel  are  easily  calculated  by  simply  averaging  of 
stresses  in  the  triangles. 


Stiffiiess  matrix  of  filler  core 


The  linear  relationship  between  filler  core  vertical  displacements  and  nodal  displacements 
is 


V  =  Co  +  cix  +  C2Z  (29) 


Shear  strains  occur  because  of  rotation  of  rigid  vertical  lines  in  the  core.  We  shall 
calculate  as  mean  arithmetical  rotation  angles  the  following 
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”  =  (31) 


Vertical  displacement  of  element  nodes  are 


V  =  {v,v,v,v,}  =  C^n  (32) 


where  «  =  {coC/C,}. 


From  Eqn.  (32),  using  a  least  squares  method,  we  find 


n  =  RV  (33) 


where  R=(CC'^  y‘  C. 


Then  strains  and  stresses  in  the  core  are 


r^L^U  (35) 


^  =  Kx'^J=Gr  (36) 
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where  Lj-  =  mRA  +  T 


(37) 


and 


1  0 
0  1 


The  stiffness  matrix  of  the  core  is 


kf  =  LffGLfV  (38) 


where  the  volume  of  the  core  is 


4 


(39) 


and 


^1234 


^32^21  ~  ^21^32 


+  \X,.Z 


34‘^3] 


■X3JZ3A 


(40) 


is  the  square  of  a  projection  of  the  element  on  the  plane.  The  stiffiiess  matrix  of  all 
elements  is  foimd  by  summing  the  stiffiiess  matrices  from  both  the  top  and  bottom  skin 
panels  and  the  stiffiiess  matrix  of  the  core  filler. 
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Appendix  7: 

AML  Dracon  Interface  Documentation  The  Use  of  Optimality  Criteria  for  Aircraft 

Conceptual  Level  Structural  Design 

Alexander  I.  Danilin* 

Terrence  A.  Weisshaar^ 


Abstract 

This  paper  illustrates  the  use  of  established  optimality 
criteria  with  deflection  constraints  to  add  information 
during  the  early  design  stage  to  aid  in  a  multi¬ 
disciplinary,  as  opposed  to  a  structural  design,  effort. 
Our  objectives  are  three:  to  estimate  weight  of  unusual 
design  components  accurately;  to  provide  stiffness 
information  when  aeroelastic  or  other  stiffness 
constraints  are  involved;  and,  to  provide  a  seamless 
path  from  conceptual  to  preliminary  design  where 
accurate,  gradient-based  optimization  methods  can  be 
applied.  This  approach  requires  a  simple,  but  accurate, 
method  to  address  static  aeroelastic  constraints  such  as 
lifting  surface  effectiveness.  We  address  aeroelastic 
constraints  by  furnishing  a  rationale  for  locating  typical 
sections  on  lifting  surfaces  (such  as  was  first  done  in  an 
ad  hoc  manner  by  Theodorsen).  Our  examples  indicate 
that  control  of  sectional  deformation  of  parts  of  lifting 
surfaces  lying  between  70%  and  90%  of  the  semi-span 
will  serve  as  a  surrogate  for  precise  aeroelastic  control. 
We  also  discuss  how  to  identify  structural  locations 
where  we  are  likely  to  find  minimum  gage  thicknesses. 
Our  approach  is  illustrated  with  two  problems:  design  of 
a  vertical  tail  with  and  without  a  lift  effectiveness 
constraint;  and,  design  of  a  supersonic  transport  wing  to 
reduce  trim  drag. 

Background 

The  purposes  of  this  paper  include:  a  historical 
perspective  on  structural  design  efforts  that 


have  occurred  in  Russia  during  the  past 
decade;  and,  suggesting  how  to  improve 
structural  conceptual  design  by  reducing  risk, 
adding  fidelity  and  encouraging  creativity. 
This  improvement  includes  the  routine  use  of 
formal  optimization  methods  for  structural 
conceptual  design  at  the  earliest  possible  time. 
Our  process  depends  on  using  optimality 
criteria  for  structural  design;  this  area  is  a 
reasonably  well-developed  analjdical 
technology.  Schmidt[l]  gives  a 

comprehensive  list  of  early  papers  in 
optimality  criteria  that  is  sufficient  for  our 
purposes. 


Most  optimality  criteria  focus  on  fully  stressed 
design.  All  optimality  algorithms  for  solution 
use  recursive  redesign  rules.  One  limitation  of 
fully  stressed  design  is  that  it  assumes  that  a 
fully  stressed  design  is  equivalent  to  a 
minimum  weight  design.  This  is  not  a 
universal  rule  and  counter  examples  abound. 
We  do  not  wish  to  revisit  these  arguments, 
except  to  say  that  the  particular  redesign 
algorithm  used  here  is  based  on  designing 
short  load  paths  into  the  structure[2].  The 
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particular  strength  of  our  method  is  that  it  uses 
a  finite  element  mesh  that,  if  fine  enough,  can 
be  used  later  for  preliminary  design,  in  which 
general  mathematical  programming 
approaches  can  be  exercised  on  appropriate 
models.  When  this  is  done,  we  have  a 
relatively  seamless  boundary  between 
primitive  conceptual  and  preliminary  design 
models. 


In  a  design  activity  there  are  always  two  tasks, 
analysis  and  synthesis.  Our  effort  is  intended 
to  bring  these  two  areas  closer  together.  We 
have  found  that  if  we  do  not  contrast  the 
difference  between  analysis  and  synthesis  at 
the  outset,  then  some  of  our  points  will  be  lost. 
In  our  context,  analysis  is  “the  activity 
directed  toward  the  installation  of  links 
between  parameters  and  characteristics  of  an 
object  that  has  already  been  designed.”  The 
definition  of  the  maximum  stress  in  a  wing 
after  all  of  its  geometrical  parameters  have 
been  selected  is  one  such  example.  We  note 
that  such  a  task  can  be  solved  both  by  a 
mathematical  simulation  and  by  a  full-scale 
experiment,  so  our  definition  of  analysis  also 
extends  to  testing  activities. 


task  of  synthesis  becomes  the  prerogative  of 
the  creative  abilities  of  human  intellect  and 
experience.  This  does  not  mean  that  humans 
always  make  good  decisions  or  that  they 
cannot  be  helped  by  analysis. 


In  the  United  States  there  are  several 
approaches  to  weight  minimization  with 
aeroelastic  constraints.  Certainly  the  most 
recognized  and  venerable  of  these  codes  are 
TSO  [cf.  Ref  3]  and  FASTOP  [cf  Ref  4], 
codes  that  date  from  the  1970’s.  FASTOP 
most  resembles  the  approach  used  here 
although  it  is  more  accurate,  but  requires  more 
design  definition  to  operate  and  thus  allows 
less  latitude  for  design  efforts.  More  recently, 
ASTROS  [5]  has  become  a  standard  for 
advanced  design  optimization  with  aeroelastic 
constraints. 


Still,  at  the  beginning  of  the  design  process, 
particularly  those  that  focus  on  new  concepts, 
focus  is  seldom  sharp.  Our  concept  addresses 
this  lack  of  clarity  and  premium  on 
understanding  of  new  concepts.  Figure  1 
shows  an  example  of  how  analysis  and 


On  the  other  hand,  synthesis  is 
“the  activity  directed  toward 
the  choice  of  a  structural  form 
and  such  parameters  for  the 
designed  object  that  minimize 
(or  maximize)  one  or  more  of 
its  characteristics  and  satisfy 
all  restrictions.”  For  example, 
the  choice  of  the  number  and 
arrangement  of  spars  and  ribs 
and  the  materials  to  use  to 
make  these  elements  is  a 
product  of  structural  s5mthesis. 
In  the  majority  of  cases  the 
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Figure  1  -  The  typical  aircraft  design  process 
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synthesis  are  organized  for  a  design  activity. 
There  is  a  need  to  reorganize  this  process  to 
take  advantage  of  advances  in  computation 
and  organizational  dynamics[6].  For  one  thing, 
the  level  of  structural  analysis  used  in 
conceptual  design  is  usually  low. 


If  the  organization  always  builds  the  same 
time  of  airplane  for  the  same  purpose,  our 
approach  will  not  be  very  useful.  If  the 
choices  are  few  the  team  needs  analysis,  not 
synthesis.  We  believe  that  the  secret  of 
successful  creative,  concurrent  design  is  the 
blending  of  analysts  and  designers,  but  we 
defer  this  extended  discussion  to  others[7]. 


Many  articles  have  been  written  about  the 
design  process  and  the  move  towards 
concurrent  design[8].  We  will  not  review 
these  articles  here,  except  to  say  that  it  is  a 
challenge  to  include  the  structural  design  to 
the  same  extent  as  aerodynamic  design  that 
can  define  outer  mold-lines  with  exquisite 
accuracy.  This  aerodynamic 

synthesis/analysis  has  been  fueled  by 
analytical  capabilities  in  aerodynamic  paneling 
codes  and  CFD.  Structural  analysis  can  also 
support  design,  but  it  is  bereft  of  definitions 
required  to  generate  models  until  it  is 
sometimes  too  late  to  make  creative 
contributions. 


Structural  design  is  loads  driven.  The 
thousands  of  loads  that  define  the  myriad  of 
skeletal  dimensions  such  as  panel  thicknesses 
cannot  be  defined  until  well  into  the  design 
process.  As  a  result,  the  chance  of  using 
creative  concepts  diminishes  as  other 
members  of  the  design  team  add  features. 
This  is  particularly  true  in  the  case  of  concepts 


that  rely  on  exploitation  of  aeroelastic  design 
features.  These  aeroelastic  tailoring  concepts 
are  stiffness  dependent  and  the  decision,  early 
in  the  design  process;  to  place  a  main  spar  at  a 
specific  point,  in  a  certain  direction  may  also 
ensure  that  a  concept,  such  as  an  active 
aeroelastic  wing,  will  not  have  a  strong 
benefit. 


During  conceptual,  structures  related  design, 
discussions  about  weight  are  serious.  For 
instance,  the  advocacy  of  a  new  concept  on  the 
basis  of  reduced  cost  or  weight  is  often  on 
“thin  ice”  and  sometimes  relies  more  on  hope 
than  hard  numbers  or  on  the  “experience”  or 
“feelings”  of  the  advocate;  these  feeling  are 
often  not  shared  by  others.  We  believe  that 
our  approach  helps  to  provide  hard  evidence 
that  can  be  generated  before,  not  after,  the 
structural  layout  is  locked  into  the  process. 
Among  our  limited  objectives  is  the  use  of 
simple  optimality  criteria  and  “typical” 
sections  to  resolve  aeroelastic  issues  as  early 
as  possible. 


Identification  of  aeroelastic  characteristic 
(typical)  sections 

Some  aeroelastic  stiffness  requirements  such 
as  lift  effectiveness  can  be  posed 
approximately  as  a  limitation  on  deformation 
(note  that  this  “limitation”  can  also  be  a 
“requirement”  for  flexibility).  To  use 
optimality  criteria,  these  constraints  enter  as 
inequalities  and,  in  the  case  of  wings,  the 
measure  of  design  stiffness  is  taken  as  an 
elastic  displacement  at  a  finite  number  of 
selected,  “characteristic”  or  “typical”  cross- 
sections. 
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The  deformations  of  these  wing  cross-sections 
and  their  aerodynamic  properties  are 
representative  of  the  elastic  twist  angle  6>(2) 
and  the  chordwise  change  of  curvature 
(camber)  of  the  structure  Af(2)  along  the 
wing;  the  coordinate  z  is  the  nondimensional 
distance  from  the  lifting  surface  root.  From 
design  experience  it  is  known  that  6  and  A/ 
contribute  approximately  the  same  effects 
when 

lM.=e  (1) 

For  large-aspect-ratio  wings  with  sections  having 
thickness-to-chord  ratios  between  10%  and  12%,  the 
change  in  camber  curvature  is  insignificant  conqDared  to 
the  elastic  twist,  and  the  condition  given  in  Eqn.  1  is  not 
found  at  any  spanwise  cross-section. 
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SO  that  is  possible  to  have  a  ratio  like  that 
shown  in  Eqn.  1  on  some  sections.  In  Figure  2 
the  curves  6'(z)  and  a7(z)  for  a  supersonic 
passenger  airplane  wing  with  an  ogival 
planform  with  thickness  ratio  5%  are  shown. 
It  is  seen  that  elastic  twist  dominates  the 
airloads  at  z  >0.5. 


Figure  3  -  Tu-154  structural  finite 
element  model 


Theodorsen  described  these  circumstances 
when  he  considered  torsional  deformations  of 
a  characteristic  section  at  the  spanwise 
position  to  be  “characteristic”  of  the  behavior 
of  the  wing  in  general.  He  did  not,  to  our 
knowledge,  publish  the  guidelines  used  to 
select  his  typical  section.  Other  researchers 
recommend  a  characteristic  cross-section 
located  at  different  z  locations.  Most 
recommend  selecting  a  characteristic  cross- 
section  in  the  range  z  =0.7  to  0.9. 


Figure  2  -  Chordwise  curvature 
and  twist  for  an  example  low 
aspect  ratio  transport  wing; 
subsonic  and  supersonic  flight 


References,  which  substantiate  the  principles  used  to 
select  a  characteristic  cross-section,  are  not  known  to 
us.  Therefore  we  conducted  a  study  to  identify  how  to 
select  such  a  section. 


For  low-aspect-ratio,  high-speed  wings  with 
thickness-to-chord  ratios  between  3%  and  5%, 
relatively  large  chordwise  deformation  occurs 


First  we  consider  the  high-aspect  wing  shown  in  Figure 
3.  This  wing  has  an  aerodynamic  aspect  ratio  AR=  7.5; 
only  the  load-carrying  part  of  a  design  is  shown.  The 
stmctural  distribution  and  the  geometrical 


characteristics  of  model  correspond  to  the  wing  of  the 
Tupelov  154  aircraft.  Let’s  determine  the  torsional 
deformations  of  cross-sections  for  tliree  loading 
conditions: 


1 .  loading  by  tip  section  ailerons 

2.  loading  by  an  inboard  flap 

3.  a  case  with  a  forward  center  of  pressure 


Because  the  relative  twist,  not  the  absolute  value  of  the 
twist,  is  important,  we  will  examine  two  different 
normalized  relationships: 


(2) 


From  this  result  it  follows  that  the  twist  at  z 
=0.75  is 


Figure  5  -  Structural  finite 
element  model  —  note  coarse 
mesh 


9  (0.75)  s  const  j9  (z)  dz.  (5) 


<3) 

jo  {z)(iz 


Figure  4  plots  these  two  relationships.  It  is 
difficult  to  draw  practical  conclusions  from  a 
plot  of  but  the  curves  62(2)  show  an 

interesting  feature.  These  three  curves 
intersect  very  close  to  each  other  at  z  =  0.75. 
We  notice  that  for  all  three  loading  conditions 
we  have 


j^(z)dz 


This  cross-section  location  is  in  the  range  z 
first  mentioned  by  Theodorsen  as  his  selection 


D.1  0,3  0,5  0.7  0,9  2 


Of  0.3  0,5  0  7  0.9  ^ 


gure  4.  Twist  deflection  results  for: 
o-flap  loading; 

A  ”  forward  center  of  pressure; 
□  -  aileron  loading. 


for  the  characteristic  section. 


Let's  try  this  approach  for  the  low  aspect  ratio 
transport  wing  whose  coarse  finite  element 
structural  model  is  shown  in  Figure  5.  The 
five  loads  applied  to  the  wing  are:  a  subsonic 
cruise  condition;  take-off;  aileron  loading  on 
element  fV;  a  twisting  moment;  and,  aileron 
loading  on  section  n.  The  results  shown  in 
Figure  6  demonstrate  that  here  too  it  is 
possible  to  find  a  characteristic  section,  in  this 
case  at  z  =  0.83. 


(6) 

Here  represent  internal  forces  in 

element  i  due  to  the  unit  loading;  /?,.  = 
represents  internal  forces  in  element  i  due  to 
the  applied  loading;  is  the  thickness  of  the 
element;  5,  is  the  planar  area  of  the 
element;  and  n  are  the  modulus  of 
elasticity  and  Poisson's  ratio  of  the  element 
material. 


As  a  result  of  this  study,  propose  the  following 
simple  technique  to  find  the  typical  section  for 
optimization  studies.  The  twist  distribution  on 
a  “typical”  wing  is  computed  for  several 
loading  conditions.  The  curves  ,  defined 
in  Eqn.  3,  are  constructed  and  the  approximate 
point  of  their  intersection  determines  the 
position  of  the  characteristic  section.  This 
gives  us  an  empirical  guide  for  optimization 
studies. 


Stiffhess  constraints  and  optimality  criteria 

To  enforce  an  approximate  aeroelastic  constraint  we 
need  a  method  for  constraining  displacements, 
particularly  those  related  to  surface  rotation.  Consider 
the  search  for  a  structural  design  with  minimal  volume 
(mass)  with  a  generalized  displacement  constraint  at  a 
single  point  on  the  structure.  To  develop  our  constraint 
relationship,  we  first  apply  a  unit  generalized  force 
(unit  load)  in  the  direction  of  the  constrained 
displacement  (either  a  displacement  or  a  rotation  such 
as  twist).  We  use  the  Maxwell-Mohr  formulas  to 
calculate  the  constrained  displacement,  called  . 

This  is  also  referred  to  as  the  unit  load  or  dummy  load 
method  formula.  We  first  assume  that  the  design  is 
divided  into  m.  finite  elements,  each  in  a  plane  stress 
condition,  so  that 


The  internal  loads  due  to  the  unit  generalized 
force  and  applied  loading  are  called  and 
Rj ;  they  are  determined  by  the  usual  finite 
element  procedure.  If  finite  elements  with  a 
constant  stress  field  are  used,  Eqn.  6  becomes: 


(7) 


Equation  7  can  be  interpreted  for  rod 
elements;  5,  is  the  length  of  the  rod;  5^  is  the 
cross-sectional  area;  and,  [/?*]  is  the  product 
of  internal  forces  of  the  basic  and  unit  loading 
cases. 


Ill 


where  is  the  given  value  of  the  generalized 

displacement. 


The  elements  of  the  series  in  Eqn.  7  provide 
the  contribution  of  each  element  to  the 
displacement,  which  is  constrained.  If  the 
value  [7?,*  ]  is  large,  the  displacement  is  largely 
determined  by  deformations  of  the  ith  element. 
If  the  size  [7?,*  ]  is  negative  then  reducing  the 
material  size  or  modulus  will  reduce  the 
deflection.  Because  the  unit  generalized  force 
is  in  the  direction  of  the  constrained 
deformations,  a  negative  value  of  the  Mohr 
integral  shows  where  it  is  necessary  to  reduce 
the  volume  of  an  element. 


Figure  6  -  Torsional  deformation 
distribution  for  low  aspect  ratio 
supersonic  transport  wing 

For  thin-walled  structures  whose  elements  are  in  a  plane 
stress  condition,  the  volume  of  material  is  written  as 

m 

V  =  (8) 

r=l 

We  minimize  this  volume  under  the  condition 
that 


A  =  (9) 


and  F  =  ^5,(J.^min  (10) 


For  an  illustration  of  this  method,  consider  a  cantilever 
beam  loaded  with  two  forces,  as  shown  in  Figure  7. 
The  tip  bending  displacement  angle  0  in  Figure  6  is  to 
be  constrained  to  be  zero.  First  apply  a  unit  bending 
moment  M  =  \  to  the  end  of  the  beam  in  the  +G 
direction  and  find  the  Mohr  integral,  defined  in  this 
case  as 


Assume  for  simplicity  that  EI=constant.  By 
multiplying  the  distribution  of  the  moments 
from  the  applied  and  unit  load  cases  we  find 
the  distribution  of  Mohr  integrals  over  the 
length  of  the  beam  shown  in  Figure  8. 
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From  the  distributions  in  Figure  8  it  is  seen 
that  the  reduction  in  bending  stiffness  between 
points  2  and  3  will  cause  an  increase  in  the 
angle  6' ,  while  the  reduction  of  stiffiiess  in  site 
1  will  result  in  a  reduction  of  6 .  The  angle  6 
of  the  tip  section  can  be  reduced  by  stiffening 
or  strengthening  zone  2-3,  or  destiffening  zone 
1,  or  taking  these  actions  simultaneously. 


Negative  values  of  the  Mohr  integrals  always  identify 
design  zones  that  are  can  be  “weakened”  to  satisfy 
displacement  constraints.  From  Eqn.  7  we  see  that  in 
these  regions  it  is  advisable  to  choose  the  minimum 
thickness  allowed  for  strength,  construction  or  other 
technological  reasons.  In  Eqn.  7  we  collect  all  terms 
bearing  a  negative  term  so  that  the  equation  is  written  as 

(12) 


Here  5^  is  the  minimum  allowable  thickness  of 
elements  with  negative  contributions  to  the 
Mohr  integrals;  ^  is  the  thickness  of  elements 
for  which  the  Mohr  integrals  are  positive;  n  is 
the  ntunber  of  elements  where  the  Mohr 
integrals  are  positive. 


1 .  We  define  two  terms 


Then 


PL/3 


Figure  8  -  Internal  loading  and 
Mohr  integral  values 

A  =  A'"-A“  (15) 


The  condition  in  Eqn.  9  will  look  like 


A^=A,+A-  (16) 


If,  in  zones  with  negative  Mohr  integrals,  the  minimally 
allowable  thicknesses  are  used,  the  thickness  of  these 
elements  are  eliminated  as  design  variable  and  we  find 
optimum  distribution  of  a  material  only  in  zones  with 
positive  Mohr  integrals.  Thus,  we  have  a  task  of 
conditional  optimization:  to  minimize  the  volume  of 
material 


Ei^i  ’ 


(13) 


n 

V  =  ^  Sj  Si  =>  min 

i=l 


(17) 


(14) 


under  the  condition  in  Eqn.  16. 


2.  LaGrange  multipliers  are  used  to  find  the  solution. 
Let's  define  a  function 


^  =  (18) 

/=! 


(a<,+a-) 


—  .  =  L2,...n. 


(23) 


where  is  the  LaGrange  multiplier.  The 
conditions  of  a  minimum  of  the  function  are: 


The  expression  in  Eqn.  23  defines  the  “law  of 
distribution”  of  a  material  for  elements  of  the 
design  ensuring  the  constraint  on  the 
^neralized  displacement  with  internal  forces 
/?,  and  7?,  . 


=  (19) 

£•,  Si 

^  =  A^-A„-A-=0  (20) 


From  Eqns.  1 9  and  20  we  have 


(21) 


Substituting  Eqn.  21  into  Eqn.  20  we  find  the 
LaGrange  multiplier 


Fig.  10  -  Vertical  tail  finite 
element  model.  Spars  are 
indicated  as  A,  b,  B.  This 
model  has  108  nodes,  157 
elements  and  321  degrees  of 
freedom. 


2.= 


(a„+a-)^ 


Let's  calculate  the  required  volume  of  the 
design  from  Eqn.  8  by  substitution  of  from 
Eqn.  23  and  the  minimally  allowable  thickness 


Equation  21,  accounting  for  Eqn.  22,  can  be 
written  as 
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v  =  - 


In 

i=\ 


[^] 


Ei 

(4,+ A') 


(24) 


Figure  9  -  Vertical  tail  example 

Let's  examine  Eqns.  23  and  24.  In  the 
presence  of  zones  with  negative  Mohr 
integrals,  that  is  at  A”  0 ,  we  have  an 
opportxmity  to  develop  a  design  with  a 
constrained  zero  generalized  displacement: 

=  0 .  Moreover,  the  satisfaction  of  the 
requirement  A^  <  0  is  possible,  provided  that 
|a^|<A”.  If  the  sites  with  negative  Mohr 

integrals  are  absent,  we  cannot  reduce  the 
existing  generalized  displacement. 


Example  -  vertical  tail  design  with  strength 
and  Stiffness  constraints 

Consider  the  task  of  designing  of  a  vertical  tail  structure 
with  yaw  loading,  but  with  the  constraint  that  it  be  lift 
effective.  The  assumed  distribution  of  this 
aerodynamic  loading  is  assumed  to  be  uniform  with  an 
intensity  that  depends  on  flight  speed  and  yaw  angle. 
The  tail  is  sweptback  so  ftiat  bending  deformation 
causes  negative  streamwise  angle  of  attack  and  reduces 
the  effectiveness  of  the  vertical  tail  to  produce  a 
restoring  moment  when  the  tail  is  displaced  sideways 
(see  Figure  9).  Our  design  problem  includes  a 
requirement  for  strength  and  a  constraint  on  stiffness  so 


that  the  tail  remains  effective.  This  latter  constraint  is 
an  aeroelastic  constraint.  The  issue  here  is  how  we  can 
increase  the  effectiveness  of  the  tail  by  structural 
redesign  and  what  it  will  cost  or  save  in  terms  of 
weight. 


Our  aeroelastic  constraint,  rather  than  directly 
addressing  aeroelastic  effects  all  along  the  entire  tail 
surface,  will  instead  require  that  there  be  a  non-negative 
angle  of  twist  of  a  characteristic  section  located  at 
distance  87.5%  of  the  distance  from  the  root  to  the  tail 
tip.  Thus,  the  stiffness  constraint  requires  that  twist  of 
vertical  tail  xmder  its  aerodynamic  loading  should  be 


Figure  12  -  Final  parameter  values  found  from 
optimization  with  strength  and  stiffness 
constraints;  parameter  values  with  minimum 
gage  are  not  shown  on  the  figure. 

opposite  to  its  “natural”  deformation. 

Our  example  has  a  3 -spar  vertical  tail  structure 
whose  coarse  geometrical  finite  element  grid  is  shown 
in  a  Fig.  10.  Ribs  are  located  along  the  streamwise 
direction  with  uniform  spacing;  the  thickness  to  chord 
ratio  of  the  structure  is  16  %.  Using  a  software  package 
DRACO  (developed  by  the  first  author  and  used 
extensively  for  structural  design  and  design  education  in 
Russia)  the  vertical  tail  structure  was  optimized. 

The  initial  structural  arrangement  has  uniform 
distributions  of  material  in  elements  within  each  of  five 
structural  element  groups.  The  initial  skin  element 
thickness  is  1  mm;  spar  web  thicknesses  are  2  mm;  rib 
webs  and  leading  edge  webs  are  1  mm;  cross  sectional 
areas  of  rib  caps  are  100  mm^;  spar  caps  are  1000  mm^. 

The  lower  limits  for  the  element  cross-section  areas  and 
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Figure  1 1  -  Final  values  found  from 
optimization  with  a  strength  constraint  only 

thicknesses  are  equal  to  0. 1  %  of  the  initial  values.  The 
allowable  stress  is  identical  for  all  elements  and  equal  to 
100  N/mm^;  the  modulus  of  elasticity  of  the  structural 
material  is  7.2  x  10^  N/mm^,  The  generalized 
displacement  constraint  is  =  0  *  The  streamwise 

twist  at  the  position  87.5%  from  the  root  of  the  vertical 
tail. 


If  we  take  into  account  only  strength  and 
minimum  gage  constraints  then,  after  three 
design  iterations,  the  distribution  of  a  material 
shown  in  Figure  1 1  is  found.  The 
characteristic  section  has  a  streamwise  twist 
angle,  =  -41.15x10’^  radians;  the  volume 

of  stractural  material  is  V  =  0.86842 1x1  O'* 
mm^. 


has  volume  Vs  =  0.876285x10^  mm^.  This 
is  only  0.9  %  heavier  than  the  design  with 
only  a  strength  constraint. 


This  type  of  problem  has  also  been 
considered,  independently,  by  Sensburg 
and  Tischler,  in  a  study  in  which  they  used 
ASTROS  and  laminate  design  to  improve 
the  effectiveness  of  a  vertical  fin[9].  Their 
results,  based  on  more  accurate  flight  loads 
also  indicate  that  lift  effectiveness  can  be 
greatly  improved  by  redistribution  and 
reorientation  of  material. 


Supersonic  trim  of  a  transport  aircraft 


Consider  the  problem  of  increasing  the  stiffiiess  of  the 
low  aspect  ratio  supersonic  wing  (previously  shown  in 
Figure  5)  to  reduce  the  trim  drag  that  occurs  during 
transition  from  subsonic  to  supersonic  flight.  A  main 
contributor  to  this  drag  is  the  elastic  deformation 
created  by  the  deflection  of  elevens  used  to  trim  the 
airplane  in  pitch.  The  stiffiiess  constraint  to  address 
this  problem  can  be  presented  as  a  permissible  value  of 
the  difference  between  wing  torsional  deformations  in 
the  subsonic  and  supersonic  cruise  modes.  Figure  13 
shows  the  distribution  of  this  difference  in  torsional 
deformation  for  the  supersonic  TU  -  144.  The  problem 
considered  was  the  re-design  of  this  wing  (a  problem 
for  which  the  results  were  not  implemented). 


When  we  include  both  the  strength  condition 
and  the  stiffiiess  requirement  (streamwise 
rotation  is  near  zero),  after  four  iterations  the 
distribution  of  material  shown  in  Figure  1 1  is 
found.  The  streamwise  twist  angle  of  the 
characteristic  section  is  -1-4.44x1 0"^ 

radians.  This  angle  is  not  quite  zero,  but  it  is 
slightly  positive  and  increases,  rather  than 
decreases,  effectiveness.  The  distribution 
satisfies  all  imposed  strength  constraints  and 


In  general,  the  re-design  of  a  wing  with  such 
stiffness  requirements  can  be  formulated  as 
follows.  Take  as  a  measure  of  design  stiffiiess 
the  twist  angle  of  the  characteristic  section 
previously  defined.  It  is  required  to  increase 
the  design  stiffiiess  with  a  minimal  weight 
increase.  We  are  required  to  find  the 
distribution  of  wing  structural  material  that 
satisfies  strength  conditions  for  all  loading 
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Twisting  angies  difference  of  wing  aerofoii 
sections 


Figure  13 -Difference  between 
supersonic  and  subsonic  twisting  angles 

conditions  and  provides  a  minimal  difference 
between  twisting  of  the  characteristic  section 
in  the  subsonic  and  supersonic  flight  phases 
and  has  minimum  mass.  To  solve  the  design 
problem  approximately,  we  do  the  following: 


1 .  Assume  that  we  know  the  optimal  shape  of 
the  wing  middle  surface,  including 
geometrical  and  aerodynamic  twist  and 
curvature  of  the  middle  surface  so  that  we 
have  minimum  aerodynamic  drag  in 
supersonic  cruise. 


2.  Determine  loads  for  all  remaining  load 
cases.  With  these  loads  we  find  the 
distribution  of  material  satisfying  only 
strength  requirements. 


3.  With  subsonic  and  supersonic  cruise  (firom 
Step  1)  we  find  a  design  that  has  a 
minimal  difference  of  torsional 
deformations  of  the  characteristic  section 
at  subsonic  and  supersonic  flight. 


Additional  thickness  for  upper  skin  [mm] 


Figure  14  -  Distribution  of  added 
mass  on  upper  wing  skins 


The  additional  material  can  be  added  to  skin  panel  and 
spar  elements,  but  should  first  be  placed  in  zones  with 
large  positive  values  of  differences  between  Mohr 
integrals  calculated  for  this  problem. 


There  are  other  less  effective  ways  to  handle  this 
problem.  These  include 


1.  Use  a  more  powerful  engine;  however,  in 
the  cruise  mode  its  additional  thrust  is  not 
necessary;  also  it  will  not  remove  control 
problems  that  occur  at  transition  to  a 
subsonic  speed. 


2.  Transfer  part  of  the  fuel  to  tail  tanks 
elsewhere  to  displace  the  center  of  mass 
aft;  this  has  several  drawbacks.  First  of 
all,  the  useful  internal  volume  of  the 
airplane  is  decreased.  For  a  fast  fuel 
transfer,  powerful  (usually  -  some  tens  of 
kilowatts)  fuel  pumps  are  required  with 
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high  output  fuel  lines.  This  makes  the 
airplane  fuel  system  and  power  supply 
system  much  heavier  and  more  costly.  In 
addition,  in  an  emergency  situation  we 
must  decrease  speed  from  supersonic  to 
subsonic  quickly.  Then  it  is  necessary  to 
dump  transferred  fuel  to  prevent 
longitudinal  instability  of  the  airplane  in 
the  subsonic  region  because  of  the  aft 
position  of  the  center  of  mass.  Despite 
these  apparent  disadvantages,  this  method 
is  often  used. 


3.  We  can  use  canards.  However,  flight  tests 
demonstrate  that  the  efficiency  at  subsonic  speed  is 
poor  and  longitudinal  balance  problems  remain.  In 
addition,  the  spin  property  of  the  airplane  with  a 
canard  configuration  is  worse  than  other  airplanes. 
Also,  an  airplane  with  a  canard  configuration  has 
poor  dynamic  stability  since  there  is  difficulty 
suppressing  short-period  oscillations. 


The  maximum  additional  material  allowed  is  1%  of  the 
original  structural  weight.  Figures  14  and  15  show  the 
results  of  placing  additional  material  in  the  skin  panels 
for  stiffening  such  that  the  difference  between  the 


Additional  thickness  for  lower  skin  |mml 
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Figure  15  -  Distribution  of  added 
mass  in  lower  skins 

subsonic  and  supersonic  twist  is  minimized. 


This  process  is  very  rapid  and  has  far  reaching 
effects  on  the  design. 


Clearly,  the  simplicity  of  an  effective  optimization 
method  can  help  a  design  team  sort  through  feasible 
solutions  to  a  serious  design  problem. 


Conclusion 

Our  procedure,  implemented  by  a  PC  software  package 
known  as  DRACO  developed  by  the  first  author  or  by 
alternative  optimization  techniques,  provides  the  ability 
to  perform  high-level  trades  early  in  the  design  process. 
Two  illustrative  examples  have  been  discussed  to  show 
the  level  of  input  detail  required  for  the  process.  This 
approach  also  places  structural  topology  with 
aeroelastic  considerations  on  an  equal,  multi¬ 
disciplinary  level  with  the  usual  aerodynamic  and 
performance  considerations  that  drive  conceptual 
design.  The  results  of  this  process  can  then  be  given  to 
high  fidelity  optimization/analysis  packages  such  as 
ASTROS  for  further  refinement  at  the  detailed  design 
level  -  if  the  design  acmally  progresses  that  far.  The 
result  will  be  a  higher  fidelity,  higher  quality  effort 
capable  of  identifying  structural  and  weight  problems 
early,  while  providing  reliable  design  information. 


This  study  illustrates  how  optimality  criteria,  coupled 
with  effective  finite  element  analysis,  can  bring 
valuable  information  to  the  initial  structural  design 
effort.  This  information  allows  the  design  team  the 
opportunity  to  review  and  debate  design  decisions 
made  by  configuration  specialists  early  so  that  good 
decisions  are  made.  Using  this  technique,  it  is  no 
longer  necessary  to  wait  to  consider  requirements  such 
as  aeroelasticity  or  other  stiffness  related  performance 
constraints. 
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